IRIX Base Documentation 2001 May/SGI IRIX Base Documentation 2001 May.iso/usr/relnotes/performer_eoe/ch5.z/ch5

Text File | 2001-04-17 | 159.0 KB | 3,829 lines

                                  - 1 -



       6.  _C_h_a_n_g_e_s__f_r_o_m__P_r_e_v_i_o_u_s__R_e_l_e_a_s_e_s

       This Chapter identifies incremental changes and enhancements
       since IRIS Performer 2.0.  Changes are presented in reverse
       chronological order, with the most recent releases listed
       first.


       6.1  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1

       6.1.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1

          +o Intersection testing was limited to geosets with fewer
            than 2^16 triangles.  This limit has been increased to
            2^32 (no SCR number).

          +o A successful intersection with an indexed triangle
            strip geoset did not fill the 'prim' field of pfHit.
            This has been fixed (SCR 816478).

          +o Intersections and picking with an off-axis viewing
            frustum was not functional.  This has been fixed, in
            both the 2.4.1 and 2.2.12 versions (SCR 803898).

          +o Intersection testing with pfDoubleDCS, pfDoubleSCS, or
            pfDoubleFCS nodes was not implemented in Performer 2.4.
            A limited fix has been made, in which single-precision
            versions of the matrices are used for the intersection
            test (no SCR number).

          +o DSO IVERSION identifiers specified by Performer had an
            invalid format, sgiX.Y.ABC.  The proper format is
            sgiX.Y.  This could cause applications using the
            backwards-compatibility libraries to fail and has been
            fixed (SCR 816478).

          +o Calling pfGetChanESky() before defining a pfEarthSky
            could cause a crash.  This has been fixed (no SCR
            number).

          +o Calling pfGetCurLights() before defining any lights
            could cause a crash.  This has been fixed (no SCR
            number).


       6.1.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4_._1

       6.1.2.1  _p_f_V_o_l_F_o_g
       OpenGL Performer 2.4.1 extends the algorithm for rendering
       layered fog by incorporating self-shadowing and scene
       shadowing. The lower parts of a dense fog or objects below a











                                  - 2 -



       dense fog then appear darker.

       Self-shadowing is enabled by setting flag 0x40 to 1.  The
       fog mode should be set to PFVFOG_EXP.  If the fog has
       different colors at different elevations and the flag 0x0100
       is set to 1 a secondary scattering of light is approximated.
       In this case the color of higher layers may affect the color
       of lower layers.  If the flag 0x80 is set the scene objects
       below a dense fog become darker.  In all these effects the
       light is assumed to come from the top.


       6.2  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _O_p_e_n_G_L _P_e_r_f_o_r_m_e_r _2._4 _a_n_d _I_R_I_S
            _P_e_r_f_o_r_m_e_r _2._2



       6.2.1  _B_e_h_a_v_i_o_r_/_A_P_I__c_h_a_n_g_e_s


       6.2.1.1  _I_R_I_S__G_L
       OpenGL Performer 2.4 supports OpenGL-based rendering only.
       IRIS GL is no longer supported.  Accordingly, the library
       DSO naming scheme has been changed.  What was previously
       _l_i_b_p_f__o_g_l._s_o (for example) is now simply _l_i_b_p_f._s_o.  Be
       certain to update your Makefiles.


       6.2.1.2  _p_f_d_u_._h__s_t_r_u_c_t_u_r_e_s_:__p_f_d_G_e_o_m_,__p_f_d_P_r_i_m
       OpenGL Performer 2.4 changes the structure of pfdPrim and
       pfdGeom in order to support multi-texture. Existing code
       using the prior version of these structures must be ported.
       The struct elements tbind, texCoords, texCoordList,
       itexCoords are now arrays of size PF_MAX_TEXTURES.

       Porting existing code, the struct members tbind, texCoords,
       texCoordList, itexCoords should be replaced by tbind[0],
       texCoords[0], texCoordList[0], itexCoords[0].

       When initializing a pfdPrim struct or when creating a
       pfdGeom struct without the function pfdNewGeom, one must
       initialize the entire array tbind[] to PFGS_OFF as in the
       code example:

           {{{{
               iiiinnnntttt        tttt;;;;
               ppppffffddddPPPPrrrriiiimmmm    ****pppp;;;; ////**** OOOOrrrr:::: ppppffffddddGGGGeeeeoooommmm ****pppp;;;; ****////

               ffffoooorrrr ((((tttt ==== 0000 ;;;; tttt <<<< PPPPFFFF____MMMMAAAAXXXX____TTTTEEEEXXXXTTTTUUUURRRREEEESSSS ;;;; tttt ++++++++))))
                   pppp---->>>>ttttbbbbiiiinnnndddd[[[[tttt]]]] ==== PPPPFFFFGGGGSSSS____OOOOFFFFFFFF;;;;
           }}}}











                                  - 3 -



       6.2.1.3  _p_f_F_l_u_x__d_e_f_a_u_l_t__n_u_m_b_e_r__o_f__b_u_f_f_e_r_s_.
       OpenGL Performer 2.4 counts a DBASE process as a pfFlux
       client. Forking a DBASE process increases the default number
       of buffers on a pfFlux by one. Previous versions of OpenGL
       Performer ignored the DBASE process when computing the
       default number of pfFlux buffers.


       6.2.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4

       6.2.2.1  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__t_h_e__b_a_s_e__l_i_b_r_a_r_y
       OpenGL Performer 2.4 introduces many architectural
       improvements to core features in the library, avoiding API
       changes so as to ensure that very little porting effort will
       be required.  These include:

          +o Multipipe scalability enhancements.  A significant
            per-pipe overhead in pfFrame() has been removed. This
            enables making many per-frame scene graph changes even
            when using a high number of graphics pipes.

          +o Cliptexture performance enhancements.  The texture
            download algorithm has been enhanced to significantly
            improve texture download speed and the accuracy of DTR
            performance.  Refer to
            /usr/share/Performer/src/sample/C++/clipdemo for an
            example.

          +o Ability to lock multiple processes on the same
            processor. Avoids deadlocks that used to occur in some
            priority configurations.

          +o Light-point process enhancements.

          +o pfFlux is enhanced.  More detailed explanation has been
            added to the Programmer's Guide.

          +o Refer to the detailed notes in the 2.2.x section for
            other enhancements since the 2.2 release.


       6.2.2.2  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__f_o_r__L_i_n_u_x
       Because both the IRIX and Linux versions of OpenGL Performer
       share a common code base and API, as enhancements and new
       features are introduced in the IRIX version, they
       simultaneously become available in Linux, and vice versa.
       In addition many internal enhancements have been made in
       OpenGL Performer for Linux to bring its core functionality
       ever closer to that available in IRIX.  Some of the
       enhancements _s_p_e_c_i_f_i_c to OpenGL Performer 2.4 for Linux
       include:











                                  - 4 -



          +o Multi-process operation (pfMultiprocess, pfMultithread)

          +o Frame-accurate timing control (pfPhase)

          +o Anisotropic Texture filtering

          +o Multi-Texture support

          +o Many performance & feature optimizations, including
            several specific to SGI Linux Desktop workstations.
       These are described in more detail below.


       6.2.2.3  _N_e_w__f_e_a_t_u_r_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4
       OpenGL Performer 2.4 includes revolutionary new support for
       sophisticated model shading, enabling users to render higher
       quality scenes far more easily than coding in OpenGL
       directly.  This release also provides several advanced
       visual effects, to better support simulation applications.
       The new features include:


       6.2.2.3.1  _p_f_S_h_a_d_e_r
       pfShader is a new approach to dramatically simplify OpenGL
       multi-pass rendering creation.  Instead of writing direct
       OpenGL code using pfDraw callbacks and draw bins, users can
       take advantage of the easy to use OpenGL Shader to create
       the same effects at modeling time.

       OpenGL Shader is a powerful appearance-modeling tool.  Using
       the Shader language and compiler, users can easily create
       shaders that describe very sophisticated multi-pass
       rendering effects. Read http://www.sgi.com/software/shader/
       for details on OpenGL Shader. The shaders can be associated
       with any pfNode in the OpenGL Performer scene graph to
       achieve high performance multi-passing rendering results
       using OpenGL Performer without writing OpenGL code directly.

       pfShader in 2.4 is our first effort at supporting OpenGL
       Shader within OpenGL Performer. The purpose is to establish
       the architecture foundation for this revolutionary approach.
       There are still many limitations in the pfShader.  Not all
       shaders created from OpenGL Shader can be supported in 2.4,
       for example, shaders with variable changes.  Further
       extensions and performance enhancements will become
       available in future regular releases.

       Man pages to see: pfShader, pfShaderManager

       Sample programs to check out:












                                  - 5 -



               /usr/share/Performer/src/pguide/libpf/C++/shader_blue_and_purple.C
               /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
               /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
               /usr/share/Performer/src/pguide/libpf/C++/shader_red_material.C
               /usr/share/Performer/src/pguide/libpf/C++/shader_test.C
               /usr/share/Performer/src/pguide/libpf/C++/shader_wood_texture.C

       Utilities to use:

               /usr/share/Performer/src/tools/ipf2pf (convert
       shader file into pfShader file)
               /usr/share/Performer/src/lib/libpfdb/libpfpfs
               /usr/share/Performer/src/lib/libpfdb/libpfpfb

       Documentation to use in addtion to Programmer's Guide:
               /usr/share/Performer/src/tools/pfshader_file_spec.txt

       pfShader Data:

               /usr/share/Performer/data/shaderExample.pfb
               /usr/share/Performer/data/shaders/*.shader


       6.2.2.3.2  _M_u_l_t_i-_p_r_o_c_e_s_s _o_p_e_r_a_t_i_o_n _i_n _L_i_n_u_x (_F_U_L_L _E_D_I_T_I_O_N
       _o_n_l_y)
       OpenGL Performer 2.4 for Linux now supports the complete
       App/Cull/Draw/Isect/Compute/Dbase/Input multiprocessing
       capabilities of OpenGL Performer for IRIX.  Likewise, the
       underlying IRIX shared arena, locks, and IPC management
       routines such as ussetlock(), usunsetlock() are available
       for developer application through /usr/include/ulocks.h.


       6.2.2.3.3  _F_r_a_m_e_-_a_c_c_u_r_a_t_e__t_i_m_i_n_g__c_o_n_t_r_o_l__i_n__L_i_n_u_x
       OpenGL Performer 2.4 for Linux now supports the complete
       FREE_RUN/LIMIT/FLOAT/LOCK pfPhase() functionality of OpenGL
       Performer for IRIX.  Note that phase control is currently
       implemented as an emulation timing layer which does not yet
       support swapbuffer synchronization to the vertical retrace;
       If your graphics card currently supports synchronization to
       vertical retrace, Phase control may be off by one video
       field.  This will be corrected as OpenGL driver improvements
       allow.


       6.2.2.3.4  _M_u_l_t_i_-_t_e_x_t_u_r_e
       OpenGL Performer 2.4 supports the application of multiple
       texture maps on a single polygon using the OpenGL multi-
       texture extension.  Currently, this feature is only
       available in OpenGL Performer for Linux.  pfGeoSet now
       accepts multiple texture coordinate arrays, and pfGeoState











                                  - 6 -



       now accepts multiple pfTexture, pfTexGen, pfTexLOD, texture
       matrices and detail textures.  The API additions are very
       straightforward.

       Man pages to see: pfGeoSet, pfGeoState

       Sample programs to check out:

               /usr/share/Performer/src/pguide/libpf/C/multiTexBox.c
               /usr/share/Performer/src/pguide/libpf/C/multiTexBox_flux.c

       Utilities to use:

               /usr/share/Performer/src/lib/libpfdu/pfdBuilder.c
               /usr/share/Performer/src/lib/libpfdu/pfdTMesher.c
               /usr/share/Performer/src/lib/libpfutil/hash.c
               /usr/share/Performer/src/lib/libpfdu/pfdGeoBuilder.c
               /usr/share/Performer/src/lib/libpfdu/pfdRebuild.c

       Loaders that support multi-texture data: Flight loader, pfb
       loader


       6.2.2.3.5  _A_n_i_s_o_t_r_o_p_i_c__f_i_l_t_e_r
       Standard mipmap filtering can induce blurring on a texture
       if the texture is applied to a polygon which is angled away
       from the viewer.  To reduce this blurring, an anisotropic
       filter can be used to improve visual quality.  The
       anisotropic filter is only available on Linux systems.

       Man pages to see: pfTexture

       Sample programs to check out:

               /usr/share/Performer/src/pguide/libpf/C/anisotropic.c
               /usr/share/Performer/src/pguide/libpf/C++/anisotropic.C


       6.2.2.3.6  _V_o_l_u_m_e__f_o_g
       pfVolFog is a new class that uses a multi-pass algorithm to
       draw the scene with fog that has different densities at
       different locations. It extends the basic layered fog
       provided by pfEarthSky and it supports two types of fog:
       layered fog and patchy fog.

       Layered fog changes only with elevation, its density and
       color is uniform at a given height. It is defined by a set
       of elevation points, each specifying a fog density and
       optionally also a fog color at the point's elevation.  The
       density and the color between two neighboring points is
       linearly interpolated.  Patchy fog has a constant density in











                                  - 7 -



       a given area. The boundaries of this area can be defined by
       an arbitrary three-dimensional object or a set of objects.

       Man pages to see: pfVolFog

       Demos to check out:

               /usr/share/Performer/src/sample/C++/volfog
               /usr/share/Performer/src/sample/C/fogfly


       6.2.2.3.7  _R_o_t_o_r__W_a_s_h
       A pfRotorwash is used to create a graph including geometry
       and pfState which represents the visual downwash effect on
       terrain or water. The geometry changes dynamically with the
       scene and position from which it is generated. Users who are
       developing helicopter demos are especially encouraged to try
       out this feature.

       Man pages to see: pfRotorwash

       Demos to check out:

               /usr/share/Performer/src/sample/C++/rotorwash


       6.2.2.3.8  _D_o_u_b_l_e__p_r_e_c_i_s_i_o_n__m_a_t_r_i_x__s_u_p_p_o_r_t  Double precision
       matrix operations are supported in this release. This
       feature is extremely helpful when rendering large databases
       where objects can be very far away from the origin.

       Man pages to see: pfDoubleDCS, pfDoubleFCS, pfDoubleSCS

       Sample programs to check out:

               /usr/share/Performer/src/pguide/libpf/C/doubleDCS.c
               /usr/share/Performer/src/pguide/libpf/C/doubleDCS2.c

       Demos to check out:

               /usr/share/Performer/src/sample/C/clipfly


       6.2.2.3.9  _A_b_i_l_i_t_y _t_o _l_o_c_k _m_u_l_t_i_p_l_e _p_r_o_c_e_s_s_e_s _o_n _t_h_e _s_a_m_e
       _p_r_o_c_e_s_s_o_r.  OpenGL Performer 2.4 adds new API for
       eliminating frame glitches when locking multiple processes
       on one processor. This API enables a temporary priority
       upgrade for low priority processes when the APP process
       waits for them.

       Man pages to see: pfProcessPriorityUpgrade,











                                  - 8 -



       pfProcessHighestPriority


       6.2.2.3.10  _D_P_L_E_X__s_u_p_p_o_r_t
       Refer to the description under 2.2.4 for details.


       6.2.2.3.11  _L_O_D__e_v_a_l_u_a_t_i_o_n__f_u_n_c_t_i_o_n
       pfLOD is extended to take a user function for picking an LOD
       result. The result of this user function is a floating point
       number. This gives users ultimate flexibility in LOD
       evaluation.

       Man pages to see: pfLOD


       6.3  _D_i_f_f_e_r_e_n_c_e__b_e_t_w_e_e_e_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._3__a_n_d__2_._2

       IRIS Performer 2.3 was the first release of Performer for
       Linux.  Please refer to the OpenGL Performer website for
       details.


       6.4  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0

       6.4.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0

          +o The IRIX PFB file loader was unable to read PFB files
            generated on Linux-based systems due to file
            endianness.  This has been fixed (SCR 786258).

          +o Performer serialized the rendering of each pfPipe on
            multi-pipe systems running in "Multi-Keyboard" or "TKO"
            mode.  This has been fixed (SCR 791376).


       6.5  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9

       6.5.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9

          +o Calligraphic light points flash in certain multipipe
            configurations.  This is the case even in
            PF_LPOINT_BOARD emulation mode.

            Each calligraphic board (including the simulated one)
            has some amount of memory which is used to specify
            light points. When performer fills up this memory
            buffer, meaning that the board can not take more input,
            it will render the remaining points in software mode.
            lpoints rendered in software mode occupy more pixels on
            screen than lpoints rendered in hardware mode, hence











                                  - 9 -



            the flashing behavior. The problem is due to the fact
            that Performer's memory book-keeping for lpoint buffers
            breaks under a couple conditions:

            1) When at least one pipe is doing calligraphics but
            pipe 0 is not 2) When calligraphics are used on non-
            consecutive pipes

            These memory book-keeping problems have been fixed in
            2.2.9 (SCR 787645).



       6.6  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8

       6.6.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8

          +o Access into Shared Memory pages is slow the first time
            each page is accessed.  This is particularly noticeable
            when paging ClipTextures.  A workaround has been
            implemented (see 'New Features' below).  SCR 606004.

          +o pfFindNode/pfLookupNode cannot find a pfGeode with
            pfNode type, though the manpage says that Performer
            uses pfIsOfType instead of pfIsExactType for those
            functions.  This has been fixed so that
            pfNode/pfLookupNode use pfIsOfType instead of
            pfIsExactType semantics (SCR 774905).

          +o

          +o The pfb loader leaks memory when a texture image file
            is not available. Loading and deleting a model with one
            texture image file missing leaks sizeof(pfTexture)
            bytes.


       6.6.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8

       6.6.2.1  _A_r_e_n_a__P_a_g_e__E_x_e_r_c_i_s_i_n_g

          +o When a forked process accesses memory in the shared
            arena, the first time it accesses each page is much
            slower than accessing that page subsequently. This
            problem becomes very pronounced when the forked process
            is striding through a large number of pages, such as
            sending large amounts of texture from the arena to the
            pipes, as is the case with cliptexturing.  In this
            case, the application will experience performance
            glitches when memory regions are accessed for the first
            time.











                                  - 10 -



            The workaround for this problem is to access a memory
            location in each page of the arena during program
            startup. This workaround makes most sense in the DRAW
            process, since it's the one that's affected most due to
            its access of large amounts of texture data.

            Performer 2.2.8 will touch each arena page in each draw
            process if the environment variable
            "_PFDRAW_EXERCISE_ARENA" is set. If the environment
            variable is set to a numerical value, each draw process
            will run through the arena the specified number of
            times, reporting how long it took to touch all the
            pages in each iteration. It's not necessary to touch
            each page more than once except to see the difference
            in access times to those pages.


       6.6.2.2  _S_u_p_p_o_r_t__f_o_r__n_e_w__O_c_t_a_n_e__g_r_a_p_h_i_c_s__h_a_r_d_w_a_r_e

          +o Performer 2.2.8 introduces support for the new Octane
            graphics hardware. If this hardware is detected,
            Performer will use OpenGL features that are on the fast
            path for this system, just as with other supported
            hardware.


       6.6.2.3  _P_o_s_t__l_p_o_i_n_t_-_d_r_a_w__c_a_l_l_b_a_c_k

          +o Some applications need to draw to the frame buffer
            after all other drawing has occurred. In the case where
            applications uses a forked LPOINT process, the drawing
            of light points happens after the draw callback is
            invoked, making it difficult to draw something on top
            of the light points.

            To get around this problem, Performer 2.2.8 now
            supports a post-lpoint-draw callback on pfChannels. To
            add such a callback to a pfChannel, use the
            "PFTRAV_POSTLPOINT" token to pfChannel::setTravFunc or
            pfChanTravFunc, for example:


            cccchhhhaaaannnnnnnneeeellll---->>>>sssseeeettttTTTTrrrraaaavvvvFFFFuuuunnnncccc((((PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT,,,, ppppoooossssttttDDDDrrrraaaawwwwFFFFuuuunnnncccc))));;;;

            The callback will be invoked regardless of
            multiprocessing mode. In applications which fork the
            LPOINT process, it will be called after the last light
            point has been drawn in each channel. In applications
            which do not fork the LPOINT process, the post-lpoint-
            draw callback will be invoked immediately after the
            draw callback returns. This callback is not reflected











                                  - 11 -



            in the stats.

            Since Performer 2.2.8 is an eoe update, we can not
            distribute header files, so to use the FTRAV_POSTLPOINT
            token, you must define it. Include the following lines
            in files using the token:


            ####iiiiffffnnnnddddeeeeffff PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT
            ####ddddeeeeffffiiiinnnneeee PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT 6666
            ####eeeennnnddddiiiiffff

       6.7  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7

       6.7.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7

          +o Triangle fans were not being correctly reported by the
            stats.  This has been fixed (SCR 769104).

          +o An array bounds underrun in _pfCuller::pf_applyXform
            could lead to memory corruption.  This has been fixed
            (SCR 767432).

          +o The prototype for pfDTRApplyImageCache was incorrectly
            documented.  This has been fixed (SCR 752840).

          +o pfNode::bufferClone could cause a segmentation
            violation.  This has been fixed (SCR 695725).

          +o The channel frustum type was being reset by
            pfChannel::pf_cullShadows.  This has been fixed (SCR
            679085).

          +o A memory leak caused by multi-pipe pfImageCache
            invalidation has been fixed.


       6.8  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6

       6.8.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6

          +o A change in the semantics of sginap() could cause
            frames to be missed if the application was running in
            FLOAT or LOCK phase and finishing its frame more than a
            full video field early.  See Chapter 4 of these release
            notes for more details.  This has been fixed in IRIX
            6.5.5 (SCR 635983).

          +o A math error when in multipass lighting mode caused
            infinite lights (those with a w coordinate of 0) to be
            transformed incorrectly through the modelview matrix,











                                  - 12 -



            producing incorrect lighting results.  This has been
            fixed.

          +o A reversed cross product caused the
            pfLightSource::setSpotDir call to rotate the light in
            the wrong direction in some cases.  This has been
            fixed.

       6.8.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6

       6.8.2.1  _M_u_l_t_i_p_a_s_s__L_i_g_h_t_i_n_g

          +o The multipass implementation introduced in 2.2.5 did
            not support fog-based range attenuation of projective
            lights.  This feature is now supported.

          +o Prior releases cleared the color buffer to red when
            generating the shadow maps for shadow-casting lights.
            Code which assumed that the shadowmap generation pass
            would clear the framebuffer to black produced incorrect
            results, so this behavior has been changed; The color
            buffer is now cleared to black when rendering the
            shadow map.  Note:  No assumptions should be made about
            the contents of the color buffer between shadowmap and
            scene rendering; always clear the color buffer when
            unsure of its contents.


       6.9  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5

       6.9.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5

          +o pfFrustum::makeOrtho() calculated incorrect near/far
            clip plane values.  This has been fixed (SCR 658920).

          +o pfGetStage() could return incorrect values due to the
            Performer clock being included in the process list.
            This has been fixed (SCR 668773).

          +o Channel-CULL callbacks registered from the .ct loader
            could collide when used in multi-channel
            configurations, resulting in the incorrect calculations
            of texture coordinates.  This regression has been fixed
            (SCR 668222).

          +o perfly, asdfly, and clipfly could not configure multi-
            hyperpipe systems.  This capability has been added (SCR
            675711).

          +o Draw statistics were only being accumulated for the
            first pipe in a hyperpipe group.  This has been fixed











                                  - 13 -



            (SCR 675517).

          +o A garbage frame would sometimes be seen when using
            texture from a DIVO source in Performer on Onyx2
            systems with 'Reality' graphics.  This was due to a
            mismatch in Performer's automatic detection of graphics
            type and has been fixed (SCR 671095).

          +o The default displacement offset for coplanar polygons
            was set too large for small frusta.  This has been
            fixed (SCR 625598, 670200).  See below for
            configuration details.

          +o Several additional improvements to the multipass
            algorithm used for projective texture pfLightSources
            have been made in 2.2.5.  In particular, the algorithm
            now supports geometry with texture based transparency
            (for example, a tree billboard).

       6.9.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5

       6.9.2.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L__1_._1__g_l_P_o_l_y_g_o_n_O_f_f_s_e_t_(_)

       This release modifies the routines used for coplanar polygon
       displacement to one based upon the polygon offset
       functionality in OpenGL 1.1.  The changes apply to all
       platforms using OpenGL 1.1 except the Impact series.

       Users may revert to the prior (Performer 2.2) behavior by
       setting the environment variable
       PF_FORCE_EXT_POLYGON_OFFSET.

       Likewise, users may choose to force the new functionality to
       be used on Impact systems (despite known bugs at this time)
       by setting the environment variable
       PF_FORCE_ARB_POLYGON_OFFSET.

       In case the results of the new offset behavior are not ideal
       for a particular system or database, users may tune the
       values set internally by IRIS Performer.  The environment
       variables PF_ARB_POLYGON_OFFSET_FACTOR and
       PF_ARB_POLYGON_OFFSET_UNITS can be set to floating point
       values which will then be used internally as arguments to
       glPolygonOffset().  See the glPolygonOffset(3G) man page for
       further details of the effect of these settings.

       Although the OpenGL 1.1 glPolygonOffset() changes were
       intended to resolve machine dependency issues, please note
       that the ideal offset factor and units value may still vary
       from system to system.  The glPolygonOffset() values set by
       IRIS Performer were chosen for typical database settings on











                                  - 14 -



       InfiniteReality systems and may require adjustment on other
       OpenGL 1.1 systems, using the environment variables
       described above.


       6.10  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4

       6.10.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4

          +o The Performer signal handler would enter an infinite
            loop if a process forked or sproc'd from the APP
            process exited.  This has been fixed (SCR 651566).

          +o Setting the PF_LPOINT_BOARD environment variable to
            enable emulation of calligraphic hardware (by using
            standard raster light points) had no effect.  This has
            been fixed (SCR 615443).

          +o Threading the lightpoint process caused a segmentation
            fault.  This has been fixed.

          +o Models containing pfLightPoints with a NULL
            pfLPointState could cause a segmentation violation on
            O2 systems running IRIX 6.5.2.  This has been fixed
            (SCR 614274).

          +o Several improvements to the multipass algorithm used
            for projective texture pfLightSources have been made.
            Colored spotlights now interact correctly with each
            other.  Note that the current algorithm does not
            support geometry with texture based transparency (for
            example, a tree billboard), and can only produce
            translucent geometry on systems with multisampling
            capability.

          +o Several pfStats::query() tokens were unimplemented.
            Most of the missing tokens can now be used to query
            statistics.  The following will still return an error:

               +o PFSTATSVAL_CPU_SECS
                 PFSTATSVAL_CPU_GFX_SWAPBUFFERS
                 PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE
                 PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_HOST
                 PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_XFORM
                 PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_FILL
                 PFSTATSVAL_GFXPIPE_TIMES_SECS
                 PFSTATSVAL_GFXPIPE_TIMES_SECS_HOST
                 PFSTATSVAL_GFXPIPE_TIMES_SECS_XFORM
                 PFSTATSVAL_GFXPIPE_TIMES_SECS_FILL













                                  - 15 -



          +o IRIX 6.5 introduced support for the concurrent use of
            shared arenas and POSIX threads (pthreads), however
            there was an error in the GLX implementation which
            prevented IRIS Performer applications from opening a
            window if the pthread library was linked.  The GLX
            implementation in the IRIX 6.5.3 overlay has addressed
            this problem, so IRIS Performer applications can now be
            safely used with pthreads.

          +o The CSB loader has been updated to enable the use of
            ClearCoat(tm).

          +o Graphics state information could "leak" from a
            cliptexture to other models in the scene.  This has
            been fixed (SCR 603185).


       6.10.2  _N_e_w__F_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4

       6.10.2.1  _S_u_p_p_o_r_t__f_o_r__D_P_L_E_X__o_p_t_i_o_n

       Performer 2.2.4 includes support for the DPLEX option to
       Onyx2 Infinite Reality. This support has been affected
       without changes to the API, and modifications to the
       command-line options for perfly, clipfly, and asdfly have
       been made to enable DPLEX. There are, however, some changes
       to the semantics of _p_f_P_i_p_e, _p_f_P_i_p_e_W_i_n_d_o_w, and _p_f_C_h_a_n_n_e_l
       interaction.  This change is described below.

       Initialization of the hyperpipe is via the existing
       pfHyperpipe() API.  This call defines the number of _p_f_P_i_p_es
       to combine into a single hyperpipe.  Each call to
       pfHyperpipe() defines a separate hyperpipe instance. For
       example, two calls to pfHyperpipe() with an argument of 2
       would define two hyperpipes of 2 _p_f_P_i_p_es each to Performer.
       Like pfMultipipe(), this routine can only be invoked prior
       to pfConfig().  Additionally, the _p_f_P_i_p_es of the hyperpipes
       will be the lowest numbered _p_f_P_i_p_es, with any non-hyperpipe
       _p_f_P_i_p_es appearing at the end.

       The first (lowest numbered) _p_f_P_i_p_e of the hyperpipe is the
       master.  In the above example, that would be _p_f_P_i_p_es 0 and
       2.  All control of the hyperpipe should be made through the
       master _p_f_P_i_p_e. For example, to construct a _p_f_P_i_p_e_W_i_n_d_o_w for
       a hyperpipe, the application can simply create it on the
       master _p_f_P_i_p_e. The cloned _p_f_P_i_p_e_W_i_n_d_o_ws for each _p_f_P_i_p_e in
       the hyperpipe will be created automatically. While allowed,
       constructing a _p_f_P_i_p_e_W_i_n_d_o_w on a non-master pipe of the
       hyperpipe will lead to undefined results.

       Hyperpipes differ from other multipipe configurations in one











                                  - 16 -



       other very important way. The set of _p_f_C_h_a_n_n_e_l_s displayed on
       the hyperpipe is shared amongst all of the _p_f_P_i_p_e_s in the
       hyperpipe.  That is, it is only necessary to create and set
       _p_f_C_h_a_n_n_e_l objects on the master _p_f_P_i_p_e of the hyperpipe.
       Since the hyperpipe is a time multiplexed view of these
       channels, Performer will propagate changes in the _p_f_C_h_a_n_n_e_l
       to each of the _p_f_P_i_p_e_s in turn.

       The following code snippet identifies the steps needed to
       setup a multi-hyperpipe config. It assumes that each of the
       hyperpipes are symetric (i.e., have the same number of
       pipes), although this is not required by Performer.


       ////****
        **** LLLLooooccccaaaallll ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnnssss
        ****////
       iiiinnnntttt iiii;;;;
       ppppffffCCCChhhhaaaannnnnnnneeeellll**** mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn;;;;
       ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn;;;;

       ////****
        **** TTTThhhheeee ffffoooolllllllloooowwwwiiiinnnngggg aaaassssssssuuuummmmeeeessss tttthhhhaaaatttt hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff
        **** hhhhyyyyppppeeeerrrrppppiiiippppeeeessss ttttoooo ccccoooonnnnffffiiiigggguuuurrrreeee aaaannnndddd hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr
        **** ppppiiiippppeeeessss ppppeeeerrrr hhhhyyyyppppeeeerrrrppppiiiippppeeee....
        ****////
       iiiinnnntttt ppppiiiippppeeeeCCCCoooouuuunnnntttt ==== hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt****hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt;;;;

       ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
           ppppffffHHHHyyyyppppeeeerrrrppppiiiippppeeee((((hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt))));;;;

       ////****
        **** CCCCoooonnnnffffiiiigggguuuurrrreeee PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr
        ****////
       ppppffffCCCCoooonnnnffffiiiigggg(((())));;;;

       ////****
        **** CCCCoooonnnnffffiiiigggguuuurrrreeee tttthhhheeee ssssccccrrrreeeeeeeennnnssss ffffoooorrrr tttthhhheeee ppppffffPPPPiiiippppeeeessss
        ****
        **** AAAAssssssssuuuummmmeeeessss aaaallllllll ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy aaaannnndddd ssssccccrrrreeeeeeeennnn aaaassssssssiiiiggggnnnnmmmmeeeennnnttttssss tttthhhhaaaatttt mmmmaaaapppp
        **** ttttoooo ppppffffPPPPiiiippppeeee nnnnuuuummmmbbbbeeeerrrr
        ****////
       ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
           ppppffffPPPPiiiippppeeeeSSSSccccrrrreeeeeeeennnn((((ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii)))),,,, iiii))));;;;  //////// aaaassssssssuuuummmmeeeessss aaaallllllll oooonnnn ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy

       ////****
        **** CCCCoooonnnnffffiiiigggguuuurrrreeee aaaa tttthhhhrrrreeeeeeee,,,, ttttwwwwoooo----ppppiiiippppeeee hhhhyyyyppppeeeerrrrppppiiiippppeeee ffffoooorrrr mmmmuuuullllttttiiii----cccchhhhaaaannnnnnnneeeellll ddddiiiissssppppllllaaaayyyy....
        ****////
       ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii ++++==== hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt)))) {{{{
           ppppffffPPPPiiiippppeeee**** pppp;;;;
           ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** ppppwwww;;;;











                                  - 17 -



           ppppffffCCCChhhhaaaannnnnnnneeeellll**** cccchhhhaaaannnn;;;;
           iiiinnnntttt sssshhhhaaaarrrreeee;;;;
           PPPPFFFFVVVVEEEECCCC3333 xxxxyyyyzzzz,,,, hhhhpppprrrr;;;;

           pppp ==== ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii))));;;;
           ppppwwww ==== ppppffffNNNNeeeewwwwPPPPWWWWiiiinnnn((((pppp))));;;;
           ppppffffPPPPWWWWiiiinnnnNNNNaaaammmmeeee((((ppppwwww,,,, """"HHHHyyyyppppeeeerrrrppppiiiippppeeee WWWWiiiinnnnddddoooowwww""""))));;;;
           ppppffffPPPPWWWWiiiinnnnCCCCoooonnnnffffiiiiggggFFFFuuuunnnncccc((((ppppwwww,,,, OOOOppppeeeennnnPPPPiiiippppeeeeWWWWiiiinnnn))));;;;
           ppppffffPPPPWWWWiiiinnnnTTTTyyyyppppeeee((((ppppwwww,,,, PPPPFFFFPPPPWWWWIIIINNNN____TTTTYYYYPPPPEEEE____XXXX))));;;;
           ppppffffPPPPWWWWiiiinnnnFFFFuuuullllllllSSSSccccrrrreeeeeeeennnn((((ppppwwww))));;;;
           ppppffffPPPPWWWWiiiinnnnMMMMooooddddeeee((((ppppwwww,,,, PPPPFFFFWWWWIIIINNNN____NNNNOOOOBBBBOOOORRRRDDDDEEEERRRR,,,, 1111))));;;;
           ppppffffCCCCoooonnnnffffiiiiggggPPPPWWWWiiiinnnn((((ppppwwww))));;;;
           iiiiffff ((((iiii ======== 0000)))) mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn ==== ppppwwww;;;;

           cccchhhhaaaannnn ==== ppppffffNNNNeeeewwwwCCCChhhhaaaannnn((((pppp))));;;;
           sssshhhhaaaarrrreeee ==== ppppffffGGGGeeeettttCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn))));;;;
           sssshhhhaaaarrrreeee ||||==== PPPPFFFFCCCCHHHHAAAANNNN____VVVVIIIIEEEEWWWWPPPPOOOORRRRTTTT |||| PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS ||||
                    PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS____HHHHWWWW;;;;
           ppppffffCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn,,,, sssshhhhaaaarrrreeee))));;;;
           ppppffffMMMMaaaakkkkeeeeSSSSiiiimmmmpppplllleeeeCCCChhhhaaaannnn((((cccchhhhaaaannnn,,,, 44445555))));;;;
           ppppffffCCCChhhhaaaannnnAAAAuuuuttttooooAAAAssssppppeeeecccctttt((((cccchhhhaaaannnn,,,, PPPPFFFFFFFFRRRRUUUUSSSSTTTT____CCCCAAAALLLLCCCC____VVVVEEEERRRRTTTT))));;;;
           ppppffffAAAAddddddddCCCChhhhaaaannnn((((ppppwwww,,,, cccchhhhaaaannnn))));;;;

           ppppffffSSSSeeeettttVVVVeeeecccc3333((((xxxxyyyyzzzz,,,, 0000,,,, 0000,,,, 0000))));;;;
           ppppffffSSSSeeeettttVVVVeeeecccc3333((((hhhhpppprrrr,,,, ((((((((hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt----1111)))) **** ....5555ffff
                        ---- iiii////hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt )))) **** 44445555....ffff,,,, 0000,,,, 0000))));;;;
           ppppffffCCCChhhhaaaannnnVVVViiiieeeewwwwOOOOffffffffsssseeeettttssss((((cccchhhhaaaannnn,,,, xxxxyyyyzzzz,,,, hhhhpppprrrr))));;;;
           iiiiffff ((((iiii ======== 0000))))
               mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn ==== cccchhhhaaaannnn;;;;
           eeeellllsssseeee
               ppppffffAAAAttttttttaaaacccchhhhCCCChhhhaaaannnn((((mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn,,,, cccchhhhaaaannnn))));;;;
       }}}}

       The remainder of the code should follow a typical multipipe
       application.

       There are certain restrictions on usage of _p_f_P_i_p_es,
       _p_f_P_i_p_e_W_i_n_d_o_ws and _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_ls when running in
       hyperpipe mode. All actions (with the exception of graphics
       pipe specific controls, e.g., pfPWinFBConfigAttrs() and
       pfPWinFBConfigId) should occur on those objects associated
       with the master _p_f_P_i_p_e.  In those instances where pipe
       specific attributes need modification, the appropriate
       pfPipeWindow or pfPipeVideoChannel can be obtained using the
       indexed pfGetPipePWin and pfGetPWinPVChan functions.  The
       index should equal the index of the associated master object
       on the master pipe.

       There is a limitation in that changes to _p_f_P_i_p_e_W_i_n_d_o_ws
       affected by the draw process will not be propagated to other
       _p_f_P_i_p_e_W_i_n_d_o_ws in the hyperpipe. Also, statistics drawn by











                                  - 18 -



       the _p_f_F_r_a_m_e_S_t_a_t_s will reflect only the times for a
       particular draw process and not the entire hyperpipe. These
       problems may be removed in a later release.


       6.11  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3

       6.11.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3

          +o Performer 2.2 always used the channel frustum for
            culling when PFCULL_GSET was set, even if a custom cull
            frustum polytope was defined.  This has been fixed.
            (SCR 635693)

          +o Attempting to delete a cliptexture could cause a core
            dump.  Cliptexture deletion is not supported, so a
            DEBUG-level warning is now emitted.  (SCR 594276)

          +o Fully transparent pfLPointStates could cause
            segmentation violations in Performer 2.2.  This has
            been fixed.  (SCR 614274)

          +o The FLT loader printed assertion failures such as the
            following:

               +o pfdConverterMode_flt: user data slot cannot be set
                 to 1

               +o pfdConverterMode_flt: private user data slot
                 cannot be set to 2

            The cause of these problems has been fixed.  (SCR
            624177)

          +o pfdFindConverterDSO was unable to locate the 3ds file
            loader. This was the result of conflicting IL and IFL
            versions and has been fixed.  (SCR 625838)

          +o The warning "pfTexture::compare(): pfClipTexture is not
            a pfTexture" was emitted when comparing a pfGeoState
            with cliptexture to one with a regular texture.  This
            has been fixed.  (SCR 626001)

          +o Picking with orthographic viewing frusta returned
            incorrect hit points.  This has been fixed.  (SCR
            601650)

          +o Color fields in pfGeoSets were not being handled
            correctly during the print traversal.  This has been
            fixed.  (SCR 621124)












                                  - 19 -



          +o pfuTravCalcBBox in trav.c did not calculate the
            bounding box for pfBillboard nodes.  It now does.  (SCR
            632225)



       6.12  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2

       6.12.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2

          +o _p_f_B_i_l_l_b_o_a_r_d_s were always using Z axis (Bug #591154)

          +o _p_f_P_i_p_e_W_i_n_d_o_w _r_e_s_i_z_e _w_i_t_h _f_o_r_k_e_d _c_u_l_l caused per-frame
            slow X communication. (Bug #611816)

          +o _p_f_T_e_x_t_u_r_e _w_i_t_h _T_e_x_L_O_D _s_e_t_t_i_n_g_s would leak memory. (Bug
            #600949)

          +o _p_f_U_n_r_e_f_D_e_l_e_t_e() would delete an object when its ref
            count was decremented to 65536.  This has been fixed,
            and the types of pfGetRef() and pfUnrefGetRef() have
            been changed from ushort to int. (Bug #603177)

          +o The _l_o_o_k_a_h_e_a_d directive was ignored in no-imagecache
            ._c_t _c_l_i_p _t_e_x_t_u_r_e _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s.  _N_O_T_E: since this
            is fixed, applications using .ct files containing a
            lookahead command may use much more memory, and may
            have to be re-tuned (or the lookahead command removed).
            (Bug #576096)

          +o The CSB loader has been updated to enable loading of
            files created by OpenGL Optimizer 1.2

          +o The FLT loader has been updated to version 15.4g (Bug
            #615990).  Several bugs have been fixed, including:

               +o A bug in revision R15.4fi where
                 pfuTexGenClipCenterNode was inserted as parent of
                 root node.  In such cases the clip texture was not
                 centered.

               +o A bug in revision R15.4fi where the loader's user
                 data slot was not initialized.  This caused core
                 dumps when certain run-time features were enabled
                 such as clip planes, behaviors, and adaptive light
                 points.

               +o _P_r_o_j_e_c_t_e_d _t_e_x_t_u_r_e_s behaved improperly when using
                 multiple channels or when lighting was off. (Bugs
                 #581332, #581334)












                                  - 20 -



               +o _I_n_f _f_r_a_m_e _r_a_t_e _r_e_p_o_r_t_e_d _f_o_r _I_n_t_e_r_l_a_c_e_d _v_i_d_e_o
                 _f_o_r_m_a_t_s.  Now, the current swap rate will be
                 reported which for interlaced video formats might
                 be faster than the requested frame rate (ie.
                 60/30Hz).  (Bug #603567).

               +o _v_i_s_f_l_y _d_e_m_o was unable to start due to an
                 unresolvable symbol in the compat libraries,
                 pfuCalcNormalizedChanXY (Bug #600942)

               +o _B_a_d _L_i_g_h_t_i_n_g - the 2.0.6/2.1.4 compat libraries
                 had bad lighting characteristics; all lit models
                 were shaded grey  (Bug #598903)

               +o _p_f_d_F_i_n_d_C_o_n_v_e_r_t_e_r_D_S_O() in 2.0.6/2.1.4 was failing
                 due to a lookup problem in pfdLoadFile.  (Bug
                 #605958)

               +o _6_4_b_i_t _o_p_e_r_a_t_i_o_n _w_i_t_h _I_R_I_X _6._5 could fail with IRIS
                 Performer 2.0 and 2.1 libraries.  This is fixed in
                 the IRIS Performer libraries that were shipped
                 with IRIX 6.5 and also in the 2.0.7/2.1.5
                 libraries.


       6.13  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1

       6.13.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1

          +o _a_s_d_f_l_y _z_b_u_f_f_e_r _p_r_o_b_l_e_m_s _o_n _i_R due to a lose layer
            offset call in asdfly/terrain.c. (Bug #575993)

          +o _M_u_l_t_i_p_i_p_e _C_a_l_l_i_g_r_a_p_h_i_c_s supports 10 pipes instead of
            just 3.  (Bug #559773)

          +o _M_u_l_t_i_p_i_p_e _p_f_G_e_t_S_c_r_e_e_n() _r_e_t_u_r_n_i_n_g (-_1)_i_n _d_r_a_w _s_t_a_g_e
            _c_a_l_l_b_a_c_k _i_n_i_t..

          +o _O_p_e_n_W_o_r_l_d_s _V_R_M_L _2._0 (._w_r_l) _l_o_a_d_e_r failed for N32 and
            N64 due to default library search path
            (/usr/lib[32,64]. (Bug #575792)

          +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _w_i_t_h _a_u_t_o_m_a_t_i_c _c_l_i_p_t_e_x_t_u_r_e
            _c_e_n_t_e_r_i_n_g could dump core if pfuInit() was not called
            by the application before pfConfig().  (Bug #575589)

          +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _u_s_i_n_g _n_e_w _1_5._4 _f_e_a_t_u_r_e_s could
            dump core due to lack of initialization of user data
            slot used for behaviors and clip planes.  (Bug #575586)













                                  - 21 -



          +o _X_s_g_i_v_c _V_i_d_e_o _C_h_a_n_n_e_l _0 had to exist or Performer would
            hang on startup.  This also caused hangs on OCTANE OCO
            (multi-channel operation).  (Bug #577815)

          +o _N_6_4 _V_i_d_e_o _c_h_a_n_n_e_l _o_p_e_r_a_t_i_o_n_s would dump core (Bug
            #575616).  To see this fix on IRIX 6.2 or IRIX 6.4,
            additional X and GL patches are required.

          +o _I_n _O_c_t_a_n_e _O_C_O _m_o_d_e  _o_r _n_o _v_i_d_e_o _c_h_a_n_n_e_l  would result
            in no pfPipeWindow being opened. (Bug #577065).

          +o _D_V_R _s_h_o_w_i_n_g _n_o_i_s_e _o_n _b_o_t_t_o_m _l_i_n_e_s _o_f _v_i_d_e_o. (Bug
            #577976).

          +o _p_f_i_S_p_h_e_r_i_c _m_o_t_i_o_n _m_o_d_e_l _t_r_a_n_s_i_t_i_o_n (rail) tracking was
            too fast for really slow speeds (in the range of
            0.000001).  (Bug #583127).


       6.13.2  _P_r_o_b_l_e_m_s _f_i_x_e_d _i_n _2._0._6 _a_n_d _2._1._4 (_s_h_i_p_p_e_d _w_i_t_h
       _2._2._1)

          +o _p_f_u_C_o_n_f_i_g_M_C_O now properly initializes multiple channels
            on multiple pipes. (Bug #564062)

          +o _p_f_W_i_n_d_o_w::_g_e_t_F_B_C_o_n_f_i_g_A_t_t_r_s() was core dumping on
            pbuffers.  It will now return NULL for a pbuffer since
            the attribute arrays is for XVisuals and pbuffers
            require GLXFBConfigSGIXs which should be specified with
            pfWindow::setFBConfig(). (Bug #575989)

          +o _p_f_u_S_a_v_e_I_m_a_g_e _i_n _N_6_4 didn't work due to bad pointer
            types in libpfutil/snapwin.c. (Bug #575243)

          +o _N_6_4 _p_l_a_c_e_m_e_n_t _o_f _p_f_D_a_t_a_P_o_o_l_s could cause brk to run out
            of space for heap area. (Bug #575065)


       6.14  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2

       6.14.1  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._0_._4__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._0_._5__a_n_d__2_._2


          +o _p_f_I_n_i_t_C_l_o_c_k in 250MHz IMPACT use not to be consistent.

          +o _P_i_c_k_i_n_g models with LOD unded DCS used to fail with
            large DCS translations (bug#455490)

          +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
            texture.












                                  - 22 -



          +o _p_f_B_o_x contains function has been fixed

          +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
            dump if the application store double float in the
            datapool.

          +o Some _q_u_e_r_y feature request were missing, 2.0.5 is now
            at the same level as 2.2.

          +o Assigning a Drawable without a visual used to cause the
            window not to open. (bug# 450891)

          +o Full screen had a window border when compiling for N64.
            (bug #542372)

          +o _p_b_u_f_f_e_r were not fully supported.


       6.14.2  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._1_._2__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._1_._3__a_n_d__2_._2


          +o When the first video channel on a graphic pipeline was
            not active, _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_l was failing under forked
            DRAW multi-process.

          +o _A_S_D _T_e_r_r_a_i_n was not supporting dynamic paging. This
            fixed so ASD tiles can be dynamically paged in the
            DBASE prmcess.

          +o _A_S_D _T_e_r_r_a_i_n was not working on multipipe. This is fixed
            and ASD works fine with multiple pipes/channels. _a_s_d_f_l_y
            is fixed as well.

          +o _V_e_r_t_e_x _a_r_r_a_y_s used in a GL display list used to produce
            invalid normals.  This has been fixed in OpenGL with
            patch 1808 or later.

          +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
            texture.

          +o _p_f_B_o_x contains function has been fixed

          +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
            dump if the application store double float in the
            datapool.

          +o Full screen had a window border when compiling for N64.
            (bug #542372)

          +o Some _q_u_e_r_y feature request were missing, 2.1.3 is now
            at the same level as 2.2.











                                  - 23 -



          +o _M_o_t_i_f decoration hints used not to work in 64 bits N64.


       6.14.3  _O_t_h_e_r__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._2

          +o _I_n_v_e_n_t_o_r loader used not to work N32/N64. (bug# 434322)

          +o _G_a_n_g_S_w_a_p was not working at all for OpenGL. This is
            fixed in performer and in OpenGL after patch 1808.

          +o _p_e_r_f_l_y did not accept input from other screens than the
            master screen. (bug# 459186)

          +o _E_a_r_t_h_S_k_y used not to propagate the right fog values in
            sync to all screens in multipipe mode (bug# 437747)

          +o _s_h_a_d_o_w _t_e_x_t_u_r_e_s used not to be implemented for
            InfiniteReality/OpenGL.

          +o _p_f_c_o_n_v did core dump or go in infinite loop when
            converting some inventor files. (bug# 435232)

          +o _g_l_o_b_a_l _s_t_a_t_e used not to work properly and be in
            conflict with channel state (see option -q0 in perfly).
            (bug# 423829)

          +o _B_i_n_s used to have many problems. Bin number had to be
            in successive numbers (bug# 416557), bin Order had no
            effect at all, there was no way to draw the objects
            that are not falling into a bin (can be done in 2.2
            using pfDrawBin(-1)), there was no way to know which
            bins are in used (pfGetFreeBin() gets that information
            in 2.2). Note that 2.2 has a predefined #3 bin: the
            Light Point bin, and that this bin has a very special
            behavior and cannot be used for general purpose.

          +o _p_f_A_S_D used to only handle terrain with less than 65000
            vertices.

          +o _p_f_d_B_u_i_l_d_A_S_D used to have memory corruptions.

          +o _D_V_R used to produce garbage when used on a screen
            larger than 1280 pixels. Performer now prevent scaling
            in X direction as the hardware does not support it. It
            is not going to be fixed in OpenGL, it is a HW
            bandwidth limitation.

          +o _g_l_N_o_r_m_a_l_i_z_e was turned on by default, resulting in a
            minimal loss of performances. Now it is automatically
            turned on only when the current transformation matrix
            includes scaling, and turned off otherwise.











                                  - 24 -



          +o Some _p_f_M_a_t_h routines were slower than system libmath
            routines that are now very optimized. The corresponding
            pfMath routines are replaced by a #define that calls
            system math routines directly.

          +o _C_l_i_p_t_e_x_t_u_r_e have been upgraded to production standards
            for IRIS Performer 2.2. The core cliptexture
            functionality has been respecified to tighter
            tolerances, critical functionality such as load control
            and virtual cliptextures has been added, and additional
            API in libpfutil and libpfdu has been put in to make
            cliptextures easier to use in production applications.

          +o _p_e_r_f_l_y -_t now allows specification of visual ID for
            each pipe as a comma-separated list.

          +o _p_f_F_o_n_t._h in previous versions was missing some internal
            fields in the class declaration that would cause
            problems for C++ user code creating pfFont structures
            and the allocates structures would not be the proper
            size.



       6.14.4  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._0_/_2_._1
       IRIS Performer 2.1 is an enhanced version of the IRIS
       Performer 2.0 release designed in conjunction with the Onyx
       InfiniteReality graphics hardware. It is, in essence,
       "Performer 2.0 with InfiniteReality extensions." Unlike IRIS
       Performer 2.1 that was only for InfiniteReality, the new
       IRIS Performer 2.2 is an enhanced version of IRIS Performer
       2.0/2.1 that runs on all SGI plateformes, enabling hardware
       specific features (DVR, ClipMapping) only when supported
       directly by the Graphic Subsystem.  IRIS Performer 2.2 has
       numerous improvements and new features over 2.0/2.1 such as
       pfFlux, pfb/pfi file formats, compute process for ASD,
       Calligraphic light support....  IRIS Performer 2.0 API is
       almost unchanged into 2.2, but it is not the case for 2.1 as
       the ClipMapping and ASD have had a lot of API changes.


       6.14.4.1  _C_l_i_p_T_e_x_t_u_r_e

       InfiniteReality supports very large textures through a
       virtual mipmapped texture scheme we call cliptexturing. Here
       is a preview of the basic concepts.

       Clip Textures provide a way use texture maps too large to
       hold in graphics texture memory. Until now, to use a large
       texture, you had to break it into tiles, bringing in the
       next texture as you approached a tile boundary.  This











                                  - 25 -



       approach has numerous problems, including what to do about
       polygons that span texture tile boundaries, properly
       handling the changes in texture coordinates, doing
       MIPMapping without visual artifacts, etc.  Performer Clip
       Textures solve these problems. They allow you to seamlessly
       use a very large texture, letting performer handle the
       loading issues.  Since it is one continuous texture, there
       are no problems with texture seams or changes in texture
       coordinates.

       A clip texture can be thought of as a very large mipmapped
       texture. The dimensions of level 0, the highest resolution
       level of the texture, is the clip texture's *virtual size*.
       For any given scene, only a subset of the entire clip
       texture is visible to the observer. pfClipTextures augment
       pfTextures by adding the notion of a center, a location in
       texel space that is close to the observer. As the center
       moves, the cliptexture must repeatedly applied, to update
       the texels in texture memory, so that contains the texels
       surrounding the current center.

       With the center properly updated, only a subset of the
       entire cliptexture need be loaded into texture memory at any
       given time. The visible region of this texture is called the
       *clip region*. The contents of this region are updated as
       the cliptexture center changes, always keeping the
       surrounding texel data available to the texturing hardware.
       The clip region can be visualized as a fixed width square
       column cutting through the mipmap levels. At the coarsest
       levels, where the MIPmap level becomes smaller than the clip
       region size, the cliptexture is a normal MIPmap pyramid. As
       the center moves on level 0, the column shears so that it
       surrounds the center, each level moving half as fast as the
       finer level above it.

       The texture itself is stored on disk and system memory as
       *tiles*. One or more tiles are stored as *texture tile
       files* on disk, and are brought into system memory as
       needed. A cache of these tiles, called the *memory region*
       is kept in system memory to reduce disk latency. A subset of
       the memory region texels, the *texture region* are
       downloaded to the graphics hardware texture memory.

       Each level of the clip texture larger than the clip size is
       contained in an level updated with the proper texel data,
       based on the center position at that level. The image cache
       must download texel data as tiles from the appropriate
       texture data files, keeping the mem region updated, and use
       texture subloads to update texel data from the texture
       region into proper area of hardware texture memory.  The
       clip texture itself is composed of image caches and image











                                  - 26 -



       tiles. The image tiles describe the levels of the mipmap
       pyramid that are equal to or smaller than the clip region.
       It updates the clip texture center, and commands the image
       caches to reapply the texture memory as the center changes.

       The application can configure a clip texture by loading
       _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s, contains information about the texel
       data, cliptexture sizes, and texture file names and
       locations. A configured cliptexture can be used in the scene
       graph like a normal pfTexture. The application can attach
       mpcliptextures to cliptextures, and pipes to mpcliptextures
       automates the cliptexture apply process each frame, and
       allows cliptexture updates to be done in the application
       process. Every frame, the application updates the
       mpcliptexture _c_l_i_p_m_a_p _c_e_n_t_e_r. This can be automated by
       adding _c_e_n_t_e_r _n_o_d_e_s nodes to the scenegraph.

       Cliptextures have a load control feature called Dynamic
       Texture Resolution (DTR). This feature allows clipmaps to be
       roamed faster than the system bandwidth would normally
       allow. DTR accomplishes this by improving the order in which
       tiles are download into image caches, and selectively
       blurring the cliptexture and adjusting the effective
       clipsize in order to modulate the cliptextures bandwidth
       requirements. DTR is controlled through a mode bitmask,
       which is used to enable or disable various load control
       features, and by a set of parameters that can be adjusted by
       the application to tune load control performance.

       There is a special form of clipmaps, called virtual
       clipmaps, which can be used to exceed some of the
       limitations in maximum virtual size and number of levels
       inherent in the system hardware. Virtual clipmaps trade off
       larger possible cliptextures against increased complexity,
       and additional interactions between the cliptexture and the
       scenegraph. With virtual cliptextues, the cliptexture,
       itself a virtualization of a MIPmap, is itself virtualized.
       The physical cliptexture is roamed within a larger virtual
       cliptexture in three dimensions; s, t, and level of detail
       (LOD). This roaming is controlled by setting the center and
       adjusting the virtualLOD offset. The number of physical
       clipmap levels in use is controlled by adjusting the
       effective levels parameter. When many levels need to be
       accessed, the virtuallodoffset and other parameters can be
       dynamically modified as the scenegraph is traversed, trading
       off some performance for much wider range of available LOD
       levels.

       Man pages to see: pfClipTexture, pfQueue, pfImageTile

       Demos to check out:











                                  - 27 -



               /usr/share/Performer/data/clipdata/hunter/run_hl
               /usr/share/Performer/data/clipdata/moffett/run_mof

       Sample programs to check out:

               /usr/share/Performer/src/pguide/libpr/icache.c
               /usr/share/Performer/src/pguide/libpr/icache_mwin.c
               /usr/share/Performer/src/pguide/libpf/cliptex.c
               /usr/share/Performer/src/sample/C/perfly

       Utilities to use:

               /usr/share/Performer/src/libpfutil/cliptexture.c
               /usr/share/Performer/src/libpfutil/clipcenter.c

       ClipTexture Texture Data and Configuration Files:

               /usr/share/Performer/data/clipdata/hunter
               /usr/share/Performer/data/clipdata/moffett
               *.ic - image cache configuration files
               *.ct - cliptexture configuration files



       6.14.4.2  _V_i_r_t_u_a_l__c_l_i_p_t_e_x_t_u_r_e_s

       Virtual cliptextures of up to 1<<23 (8 million) texels on a
       side are supported by IRIS Performer 2.2.  This allows a
       real cliptextures (currently limited in size by the
       InfiniteReality hardware to at most 32Kx32K texels) to be
       embedded in a larger virtual clipmap of up to 8Mx8M texels.

       The application controls the position of the real
       cliptexture within the virtual cliptexture by updating the
       center and the _v_i_r_t_u_a_l _L_O_D _o_f_f_s_e_t. The offset adjusts the
       real cliptexture in the LOD direction.  The real cliptexture
       can only occupy positions that are valid subsets of the
       virtual cliptexture. The number of valid locations can be
       increased by using less _e_f_f_e_c_t_i_v_e _l_e_v_e_l_s The real
       cliptexture will automatically be centered around the
       current center of the virtual cliptexture, which the
       application sets on a per-frame basis (see above).

       Utilities are provided for intelligently selecting where to
       offset the real clipmap within the virtual clipmap each
       frame.  For details, see the source code for
       pfuCalcSizeFinestMipLOD in libpfutil, and play with the
       "Clip LOD Offset" slider in perfly when viewing a clip
       texture bigger than 32Kx32K.













                                  - 28 -



       6.14.4.3  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n

       A pfASD is a pfNode which can handle very large terrain
       surfaces that are described as multiple LODs.  Active
       Surface Definition accuratedly describes different portions
       of the terrain using triangles from different LODs.  The
       multiple LODs have a coherent subdivision-surfaces-like
       relationship between the neighboring levels.  pfASD contains
       a small scene graph that is generated dynamically to reflect
       the current visible geometry being rendered.

       These routines implement the Active Surface Definition (ASD)
       feature.  ASD defines a hierarchical structure that
       organizes all the LODs of a terrain. At run-time, ASD
       traverses the structure, selecting triangles from different
       LODs to render the portion of the terrain that is within a
       volume of interest. Triangles are rendered either at their
       pre-stored locations, when they are in a particular LOD
       range, or at computed morphed locations, when they are
       within the morphing zone of a LOD range. There will be other
       ways to evaluate the terrain other than purely range based
       approach. The way to evaluate each vertex is the "evaluation
       function".  The evaluation function can be defined as a user
       call back function, when the default range based evaluation
       is not appropriate.

       An example of a user defined callback function can be found
       in

               /usr/share/Performer/src/sample/C/asdfly/eval_function.c


       pfASD has its own thread when user claimed multiprocessing
       mode, e.g.  PFMP_FORK_COMPUTE. Asychronizely, the evaluation
       of the structure is done in the thread and the created
       geometry (active mesh) are merged into the scenegraph
       internal to pfASD at pfFrame time.  pfASD enlarges the
       viewing frustum to accommodate the delay of evaluation.

       The cull of pfASD is handled together with the evaluation.
       In another word, the gsets that are generated by evaluation
       is the set of triangles that should be or soon to be
       visible.

       pfASD handles multichannel evaluation and ensures that
       neighboring channels will have consistently connected
       triangles.  A channel can also share the evaluated active
       mesh from another channel using pfChannel::ASDattach.  pfASD
       handles multipipe as well.













                                  - 29 -



       6.14.4.4  _F_l_u_x__a_n_d__E_n_g_i_n_e

       A _p_f_F_l_u_x is a container for holding dynamic data.  It
       contains multiple buffers of data each associated with a
       frame number.  This allows multiple processes to each have a
       copy of the data appropriate to the frame they are working
       on. A full pfGeoSet can be fluxed pfFlux should be used
       instead of pfCycleBuffer as they do not require a copy of
       the data to be done to synchronize the stages of the process
       pipeline.

       A _p_f_E_n_g_i_n_e is an object that controls the dynamic data in a
       pfFlux.  A pfEngine of type PFENG_MORPH associated with a
       pfFlux replaces a pfMorph node.

       see _p_f_F_l_u_x, _p_f_E_n_g_i_n_e, _p_f_F_S_C, _p_f_S_w_i_t_c_h and _p_f_L_O_D man pages.


       6.14.5  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._1


       6.14.5.1  _C_l_i_p_M_a_p_p_i_n_g

       _p_f_I_m_a_g_e_C_a_c_h_e renamed some API calls (the corresponding gets
       are  not shown)


               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeOOOOrrrriiiiggggiiiinnnn
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnOOOOrrrrgggg



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeSSSSiiiizzzzeeee
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnOOOOrrrriiiiggggiiiinnnn
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnOOOOrrrrgggg



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDsssstttt
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxx













                                  - 30 -



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDssssttttSSSSiiiizzzzeeee
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxSSSSiiiizzzzeeee



               wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVViiiirrrrttttuuuuaaaallllSSSSiiiizzzzeeee
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeIIIImmmmaaaaggggeeeeSSSSiiiizzzzeeee



               oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCeeeennnntttteeeerrrr
               oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMaaaaxxxxUUUUppppddddaaaatttteeeeSSSSiiiizzzzeeee



               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccTTTTeeeexxxxRRRReeeeggggiiiioooonnnn
               nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccMMMMeeeemmmmRRRReeeeggggiiiioooonnnn


       _p_f_Q_u_e_u_e as new functionality


               nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttMMMMooooddddeeee
               nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttFFFFuuuunnnncccc
               nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
               nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
               nnnneeeewwww:::: ppppffffGGGGeeeettttQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD


       _p_f_I_m_a_g_e_C_a_c_h_e now use sorting queus Image cache configuration
       files have a version2.0 format. The parser will run with
       either format. The new format is a little more robust and
       easier to use. The parser also now calls separate pfutil
       functions that do the creation and configuration work. This
       will make it easier to create custom configuration routines.

       The configuration files now support relative pathnames.
       Cliptexture configuration files can now be created that
       don't need image cache configuration files.


       6.14.5.2  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n

       _l_i_b_p_f_s _n_o _l_o_n_g_e_r _e_x_i_s_t_s. You should make sure you no longer
       link with it. pfTerrain no longer exists either.  All
       PFTERRAIN_ tokens have been renamed PFASD_.  Aligning object
       to pfASD uses pfFlux and pfEngine.


           ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ****ggggssss))))












                                  - 31 -



       is now


           ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ********ggggssss,,,, iiiinnnntttt nnnnuuuummmm))))

       It is important that when you port to this new api you use
       pfMalloc to allocate the array of pfGeoState pointers.

       So:


               ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((aaaassssdddd,,,, ggggssss))));;;;

       Should become:


               {{{{
                  ppppffffGGGGeeeeooooSSSSeeeetttt ********ggggssssssss;;;;
                  ggggssssssss ==== ((((ppppffffGGGGeeeeooooSSSSeeeetttt ********))))ppppffffMMMMaaaalllllllloooocccc((((ssssiiiizzzzeeeeooooffff((((ppppffffGGGGeeeeooooSSSSeeeetttt********))))****1111,,,,
                               ppppffffGGGGeeeettttSSSShhhhaaaarrrreeeeddddAAAArrrreeeennnnaaaa(((())))))));;;;
                  ggggssssssss[[[[0000]]]] ==== ggggssss;;;;
                  ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((aaaassssdddd,,,, ggggssssssss,,,, 1111))));;;;
               }}}}

       PFTERRAIN constants have become PFASD constants pfs prefix
       has become pfASD pfsFace data structure has become pfASDFace
       and the field names have been changed to properly reflect
       the functionality.

       A current version of the Muligen loader is supplied to
       handle these changes

       New sample programs including examples of aligning features
       and moving objects to ASD geometry.

               /usr/share/Performer/src/pguide/libpf/C/ASD_align.c

       New sample program that demonstrates the pfASD data
       structure

               /usr/share/Performer/src/pguide/libpf/C++/simpleASD.C


       pfASD can be paged in as simle areal blocks, as handled by
       Multigen CAT feature.

       pfASD also supports a multi-resolution paging scheme, very
       similar to clipmap paging. An example of the construction of
       pfASD from a set of uniform elevation data  can be found in













                                  - 32 -



               /usr/share/Performer/src/lib/libpfdu/pfdBuildASD.c

       Inside the same file, you can find routines that constructs
       paging ASD tiles from a fully built ASD structure. Please
       notice that the builder is for demonstration purposes
       mainly. The algorithm used is not sophisticated enough to
       provent terrain from visible morphing distortion during
       real-time fly through. The demo "yosemite" provided on 2.2
       demo CD is constructed using CAT feature in Multigen.

       Paging construction example can be found in

               /usr/share/Performer/src/pguide/libpf/C/buildarcinfo.c
               /usr/share/Performer/src/pguide/libpf/C/buildbw.c
               /usr/share/Performer/src/pguide/libpf/C/builddem.c
               /usr/share/Performer/src/pguide/libpf/C/builddted.c

       Executing the command, e.g.

               buildbw elevation.bw bw/tile bw/config bw/page

       will put a set of paging tiles under the directory bw, with
       prefix "tile" as their file names. Once you decide on how
       many extra tiles to page on each LOD based on LODRange as
       well as the paging delay, you MUST process the tiles one
       more time into a fast paging binary format before feeding it
       into a paging pfASD node.

       The second pass paging data construction can be found in

               /usr/share/Performer/src/pguide/libpf/C/convasd.c

       For example,

               convasd bw/config bw/page

       will process the tiles.  The final step is to hand all the
       attributes defined in the config file and page file to pfASD
       by calling

               pfdLoadConfig(config, page);



       6.14.5.3  _O_p_e_n_G_L__V_e_r_t_e_x__A_r_r_a_y_s

       The OpenGL _V_e_r_t_e_x_A_r_r_a_y extension is supported by IRIS
       Performer as an optimized way to send formatted data to the
       graphics pipeline, reducing the host interface.

       Vertex arrays use a new pfGSetAttr list, PFGS_PACKED_ATTRS,











                                  - 33 -



       that includes a separate copy of the vertex attribute data
       packed into a single non-indexed array.  Your vertex
       coordinates may optionally be in this packed array.  A
       sample program that demonstrates the use of vertex arrays on
       pfGeoSets is in:

               /usr/share/Performer/src/pguide/libpr/packedattrs.c

       Additionally, there is a utility traversal,
       pfuTravCreateVertArrays, that will traverse the scene graph
       and create vertex arrays for the pfGeoSets and optionally
       pfDelete the other redundant attribute arrays.  The utility
       routines used by this traversal to actually pack the
       pfGeoSet data is  pfuFillGSetVertArray().  This traversal
       can be invoked on the Perfly sample application with the -v
       # option where # is 1 or 2 to select one of two packed
       formats of with or without the vertices copied into the
       vertex array, respectively.


       6.14.5.4  _O_p_e_n_G_L__s_p_l_i_n_e__F_o_g

       InfiniteReality supports the specification of a fog function
       so Spline Fog support for OpenGL has been added to IRIS
       Performer and will be available on machines that support it.


       6.14.5.5  _T_F_a_n_s

       IRIS Performer 2.2 supports Triangle Fans in a pfGeoSets
       when using OpenGL


       6.14.5.6  _A_s_y_n_c_h_r_o_n_o_u_s__D_y_n_a_m_i_c__D_a_t_a

       IRIS Performer 2.2 supports truly asynchronous dynamic data
       with _p_f_F_l_u_x.  Data for geometry attributes in pfGeoSets and
       fields in various pfNodes can be computed in fully
       asynchronous processes and store in a pfFlux buffer.  pfFlux
       will manage the the hookup, data exclusion, and frame
       management accurate book-keeping.  pfFluxes can be
       explicitly driven by _p_f_E_n_g_i_n_e_s for defining the functions
       that generate the dynamic data.

       pfGeoSets themselves can be fluxed and fluxed pfGeoSets can
       be given to a pfGeode directly.

       pfEngines can be used to control the data in a flux. A
       complete graph of pfEngines and pfFlux can be done to
       control the dynamic behavior of a database. Both pfEngines
       and pfFluxes are stored in the performer binary file format











                                  - 34 -



       (pfb), even external functions used by pfEngines can be
       registers into the pfb and the right DSO will automatically
       be loaded when the pfb file will be used in Performer.


       6.14.5.7  _L_i_g_h_t__P_o_i_n_t

       A new light point process can be forked off and use a cpu to
       do the _p_f_L_P_o_i_n_t_S_t_a_t_e computation instead of taking time of
       the Draw Process.  The light point process is synchronous to
       the Draw process, and also support Calligraphic Light points
       when the Calligraphic Board and Projector are hooked to the
       system. To learn more about raster and calligraphic lights
       see the pfLPointState and _p_f_C_a_l_l_i_g_r_a_p_h_i_c man pages, as well
       as the pfChannel man pages to see how the light point
       process works.


       6.14.5.8  _N_e_w__l_o_a_d_e_r_s

          +o Loaders for creating pfASD structures from elevation
            data are now include in IRIS Performer 2.2
            _l_i_b_p_f_d_b/_l_i_b_p_f_d_e_m - This loader handles a variety of the
            USGS DEM elevation data products, including the common
            7.5 minute (1:24,000) and 1 degree (1:250,000) DEM
            files.  _l_i_b_p_f_d_b/_l_i_b_p_f_d_t_e_d - This loader handles DMA
            DTED Level 1 and 2 elevation data products.
            _l_i_b_p_f_d_b/_l_i_b_p_f_a_r_c_i_n_f_o - This loader handles elevation
            data files in the simple ARC/INFO ASCII GRID export
            format.  _l_i_b_p_f_d_b/_l_i_b_p_f_e_v_t - This loader reads data in
            the temporary ".evt" binary format.
            The loaders read the elevation data from the file and
            construct an appropriate pfASD node structure.  The
            origin coordinates of the created pfASD node will be
            set to the southwest corner, zero altitude point of the
            elevation data area.  The data will be oriented in the
            XY plane for elevation data specified in planar
            coordinates (such as UTM), or oriented properly on the
            earth ellipsoid for data specified in geodetic
            coordinates (Z-axis towards North Pole, X-axis defined
            by the intersection of the prime meridian and
            equatorial planes).  Use pfdBuildASD to indicate the
            levels of detail you wish to build.  That is the last
            parameter in pfdBuildASD().

            The function "libpfdu/pfdBuildASD()" can be used to
            construct pfASD structures for elevation data not
            handled by the above loaders.  There are support for
            building paging tiles in pfdBuildASD(). It is not
            turned on by default. Set the PAGING constant in
            pfdBuildASD.c to 1 if you want to experiment with











                                  - 35 -



            paging pfASD tiles.


          +o A VRML 2.0 loader is included. This loader is a gift
            from DrAW Computing Associates and will successfully
            the geometry and texture of many VRML2.0 files. To have
            more VRML 2.0 support, such as Routes, JAVA,
            saveToVrml, html direct access from performer, or to
            report any problem with the VRML 2.0 loader you will
            have to contact them directly at [e-mail].
            See the demos under openworlds in the Friend of
            Performer 2.2 CD.  Note that VRML 1.0 files are not
            supported by this loader. Previously the case, so you
            have either to convert your VRML1.0 files to VRML2.0,
            or to explicitly name your files .iv so the inventor
            loader will be used in place of the VRML 2.0 loader.


          +o A OpenGL Optimizer binary file loader (csb) is part of
            IRIS Performer 2.2 distribution. This allow exchange of
            files in between the two products as OpenGL Optimizer
            reads IRIS Performer binary files (pfb). Note that the
            pfb loader for Optimizer has a problem that changes all
            opaque polygons to fully transparent and vice-versa.
            This will be fixed, and a new pfb loader for OpenGL
            Optimizer will be available on the Web. (see section 4
            of release note)



       6.14.5.9  _C_o_p_l_a_n_a_r__g_e_o_m_e_t_r_y

       Layer and Decal geometry may now use the new OpenGL
       reference plane.  Reference planes may be specified on
       pfGeoSets, pfGeoStates, and in the global state.  See the
       pfGeoSet and pfDecal, and pfGeoState reference pages for
       more information.


       6.14.5.10  _T_e_x_t_u_r_e__m_a_t_r_i_c_e_s
       Texture matrices may now be specified on pfGeoStates.  See
       the pfGeoState reference page for more information.


       6.14.5.11  _T_r_a_v_e_r_s_a_l_s
       libpfutil traversal, pfuTravCompileDList, traversal for
       traversing an entire scene graph and creating display lists
       for all pfGeoSets.  This is to be used in combination with
       pfuTravDListDraw and is useful for compiling and pre-
       downloading display lists on InfiniteReality.












                                  - 36 -



       6.14.5.12  _V_i_d_e_o__t_e_x_t_u_r_i_n_g

       There is one main sample program for video texturing:

          /usr/share/Performer/src/pguide/libpf/C/movietex.c

       a multiprocessing example.  Note that all video
       initialization, including the creation of video library
       resources, is done in the draw process, as required by the
       video library. The program has #define switches for
       compilation on IRIX 6.2 or IRIX 6.5 and supports DIVO,
       Sirius, OCTANE, and O2 video options.  Movitex.c uses
       features added in Performer 2.2: special pfTexture LOAD
       source parameters for specifying dmedia buffers or the video
       library server, path and drain, as well as the texture
       matrix that can be specified on a pfGeoState with the
       PFSTATE_TEXMAT attribute for transforming texture
       coordinates int the proper area of a texture receiving video
       input.

       An old Sirius example has been retained in
       /usr/share/Performer/src/pguide/libpr/C/siriusvidtex.c.


       6.14.5.13  _T_e_x_t_u_r_e__L_O_D__o_b_j_e_c_t

       New pfTexLOD object for controlling LOD of textures.
       pfTexLOD is a new state attribute used to control the use of
       levels of detail of a pfTexture.  The levels of detail
       accessed can be limited by setting the LOD range and the
       computation of the current LOD value can be biased.  These
       controls are useful in conjunction with dynamic texture
       loading where the accessed levels can be limited to the
       valid levels and for artificially blurring or sharpening a
       texture.


       6.14.5.14  _N_e_w__f_a_s_t__i_m_a_g_e__f_i_l_e__f_o_r_m_a_t

       There is now the pfi fast image file loader to complement
       pfb.  pfi files are hardware-ready fast loading image files
       that may contain MIPmaps for textures and multiple complete
       textures.

       /usr/share/Performer/src/sample/pfconv.c

       can convert a database to use pfi files for its textures. In
       addition, there is a

       /usr/share/Performer/src/sample/pficonv.c












                                  - 37 -



       for converting .rgb files to pfi files and generating
       MIPmaps.  Look at the data/town/town_ogl_pfi.pfb database.


       6.14.5.15  _p_f_C_h_a_n_n_e_l
       Here are the additional C++ member functions added in
       Performer 2.2 to those already provided in IRIS Performer
       2.1 for the pfChannel class. Each C++ function has a
       corresponding C function, and all are fully described in the
       IRIS Performer 2.2 C and C++ Reference Pages.


           ggggeeeettttFFFFrrrraaaammmmeeeePPPPVVVVCCCChhhhaaaannnn
           sssseeeettttOOOOuuuuttttppppuuuuttttVVVViiiieeeewwwwppppoooorrrrtttt
           sssseeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
           ggggeeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
           sssseeeettttCCCCaaaalllllllliiiigggg
           ggggeeeettttCCCCaaaalllllllliiiigggg
           ggggeeeettttCCCCuuuurrrrCCCCaaaalllllllliiiigggg
           ggggeeeettttFFFFrrrreeeeeeeeBBBBiiiinnnn
           AAAASSSSDDDDAAAAttttttttaaaacccchhhh
           AAAASSSSDDDDddddeeeettttaaaacccchhhh

       6.14.5.16  _p_f_D_i_s_p_L_i_s_t

       This is the additional C++ member function added in
       Performer 2.2 to those already provided in IRIS Performer
       2.1 for the pfDispList class. This function allows the
       contents of one IRIS Performer pfDispList to be appended to
       a second pfDispList, supporting the merge of independent
       pfDispLists.  The _p_f_D_i_s_p_L_i_s_t::_a_p_p_e_n_d C++ function has a
       corresponding C function (_p_f_A_p_p_e_n_d_D_L_i_s_t), and both are fully
       described in the IRIS Performer 2.2 C and C++ Reference
       Pages.


           ggggeeeettttGGGGLLLLHHHHaaaannnnddddlllleeee
           sssseeeettttMMMMooooddddeeee
           ccccoooommmmppppiiiilllleeee
           pppprrrreeeepppprrrroooocccceeeessssssss

       6.14.5.17  _p_f_Q_u_e_u_e

       Here are the additional C++ member functions added in
       Performer 2.2 to those already provided in IRIS Performer
       2.1 for the pfQueue class.  These new functions add support
       for having a sort process that will sort the items in the
       queue.  Each C++ function has a corresponding C function,
       and all are fully described in the IRIS Performer 2.2 C and
       C++ Reference Pages.












                                  - 38 -



           ggggeeeettttEEEElllleeeemmmmeeeennnnttttSSSSiiiizzzzeeee
           sssseeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
           ggggeeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
           ggggeeeettttSSSSoooorrrrttttMMMMooooddddeeee
           sssseeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
           ggggeeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
           ggggeeeettttOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
           ggggeeeettttSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
           iiiinnnnsssseeeerrrrttttFFFFrrrroooonnnntttt
           aaaatttttttteeeemmmmppppttttRRRReeeemmmmoooovvvveeee
           ssssiiiiggggnnnnaaaallllAAAAllllllllSSSSeeeerrrrvvvviiiicccceeeePPPPrrrrooooccccssss
           nnnnoooottttiiiiffffyyyySSSSoooorrrrttttPPPPrrrroooocccc

       6.14.5.18  _p_f_I_m_a_g_e_T_i_l_e

       Here are the additional C++ member functions added in
       Performer 2.2 to those already provided in IRIS Performer
       2.1 for the pfQueue class.  Each C++ function has a
       corresponding C function, and all are fully described in the
       IRIS Performer 2.2 C and C++ Reference Pages.


          sssseeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
          ggggeeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
          iiiissssLLLLooooaaaaddddiiiinnnngggg
          sssseeeettttPPPPrrrriiiioooorrrriiiittttyyyy
          ggggeeeettttPPPPrrrriiiioooorrrriiiittttyyyy
          sssseeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
          ggggeeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
          sssseeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
          ggggeeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
          sssseeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
          ggggeeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
          RRRReeeeaaaaddddDDDDiiiirrrreeeecccctttt
          RRRReeeeaaaaddddNNNNoooorrrrmmmmaaaallll

       6.14.5.19  _p_f_C_l_i_p_T_e_x_t_u_r_e

       Here are the additional C++ member functions added in
       Performer 2.2 to those already provided in IRIS Performer
       2.1 for the pfQueue class.  New functions deal with DTR,
       which is a tight control on how much time you want to
       allocate in the DrawProcess to dynamically load the texture
       versus drawing polygons, and control of Virtual (bigger)
       clip textures.  Each C++ function has a corresponding C
       function, and all are fully described in the IRIS Performer
       2.2 C and C++ Reference Pages.


           ggggeeeettttCCCCuuuurrrrCCCCeeeennnntttteeeerrrr
           sssseeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt











                                  - 39 -



           ggggeeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
           sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
           ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
           sssseeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
           ggggeeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
           ggggeeeettttOOOOffffffffsssseeeetttt
           sssseeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
           ggggeeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
           sssseeeettttMMMMaaaasssstttteeeerrrr
           ggggeeeettttMMMMaaaasssstttteeeerrrr
           ggggeeeettttSSSSllllaaaavvvveeee
           sssseeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
           ggggeeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
           sssseeeettttDDDDTTTTRRRRMMMMooooddddeeee
           ggggeeeettttDDDDTTTTRRRRMMMMooooddddeeee
           ggggeeeettttMMMMiiiinnnnDDDDTTTTRRRRLLLLOOOODDDD
           ggggeeeettttDDDDTTTTRRRRFFFFaaaaddddeeeeCCCCoooouuuunnnntttt
           sssseeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
           ggggeeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
           sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
           ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
           sssseeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
           ggggeeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
           sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
           ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
           sssseeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
           ggggeeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
           ggggeeeettttCCCCuuuurrrrLLLLOOOODDDDRRRRaaaannnnggggeeee
           sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassss
           ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassss
           ggggeeeettttCCCCiiiirrrrLLLLOOOODDDDBBBBiiiiaaaassss
           aaaappppppppllllyyyyMMMMeeeemmmmRRRReeeegggg
           aaaappppppppllllyyyyTTTTeeeexxxxRRRReeeegggg
           uuuuppppddddaaaatttteeeeMMMMeeeemmmmTTTTeeeegggg
           uuuuppppddddaaaatttteeeeTTTTeeeexxxxRRRReeeegggg
           uuuuppppddddaaaatttteeee
           iiiinnnnvvvvaaaalllliiiiddddaaaatttteeee
           aaaappppppppllllyyyyVVVViiiirrrrttttuuuuaaaallllPPPPaaaarrrraaaammmmssss
           aaaappppppppllllyyyyCCCCeeeennnntttteeeerrrr
           iiiissssVVVViiiirrrrttttuuuuaaaallll

       6.15  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _I_R_I_S _P_e_r_f_o_r_m_e_r _2._0 _a_n_d _p_r_e_v_i_o_u_s
             _r_e_l_e_a_s_e_s

       This section elucidates the changes and enhancements between
       the prior IRIS Performer 2.0 release and the even older IRIS
       Performer 1.2 release. Since all the 2.0 features are
       included in 2.2 this concerns porting from 1.2 to 2.2 as
       well.













                                  - 40 -



       If you are new to IRIS Performer or if you have already
       converted your applications to the more recent 2.0 release
       you can skip this section, since the information contained
       here is provided merely to ease porting efforts for older
       applications. These features are also described in the the
       IRIS Performer Programming Guide.


       6.15.1  _N_e_w__F_e_a_t_u_r_e_s

       6.15.1.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L
       Performer 2.0 includes separate sets of libraries for
       supporting IRIS GL or OpenGL interfaces. These libraries
       have GL-dependent suffixes to indicate their type: IRIS
       GL=_igl and OpenGL=_ogl

           IIIIRRRRIIIISSSS GGGGLLLL:::: lllliiiibbbbppppffff____iiiiggggllll....ssssoooo

           OOOOppppeeeennnnGGGGLLLL:::: lllliiiibbbbppppffff____ooooggggllll....ssssoooo

       Porting an IRIS Performer application from IRIS GL to OpenGL
       should require very little work.  There are a couple of
       isolated routine changes (see API changes below).  The main
       work will be in porting an application IRIS GL code in user
       draw callbacks and in porting the windowing and event
       handling to X.  For porting windowing code, pfWindows and
       pfPipeWindows (libpr and libpf, respectively) provide a GL
       independent windowing environment.  Libpfutil provides GL-
       input handling utilities for libpf applications using
       pfPipeWindows (pfuInitInput()).  The sample programs
       installed in

           ////uuuussssrrrr////sssshhhhaaaarrrreeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ssssrrrrcccc////ppppgggguuuuiiiiddddeeee////{{{{lllliiiibbbbpppprrrr,,,,lllliiiibbbbppppffff}}}}////pppprrrrooooggggssss

       also demonstrate comparative X vs GL input handling.

       When compiling for IRIS GL, use '-DIRISGL' on the command
       line to include the IRIS GL versions of the Performer header
       files.


       6.15.1.2  _6_4_-_b_i_t__a_d_d_r_e_s_s__s_p_a_c_e__s_u_p_p_o_r_t

       6.15.1.3  _P_e_r_f_o_r_m_e_r__E_n_v_i_r_o_n_m_e_n_t__V_a_r_i_a_b_l_e_s__a_n_d__D_S_O_s
       Performer now robustly supports the notion of separate run-
       time file loaders as DSO's (Dynamic Shared Objects).  Thus,
       the generic utility method for opening a file now differs
       considerably - the extension of the filename is used to
       determine the name of shared object to load as well as the
       function within that shared library to call.  Two new
       environment variables exist to help locate these dynamic











                                  - 41 -



       shared object libraries at run-time:

          +o PFLD_LIBRARY_PATH Specifies a colon separated list of
            directories where Performer should look for dynamic
            objects...

          +o PFHOME Specifies the root Performer directory (the root
            used to install Performer).  This is used such that
            various code in the libraries can look relative to this
            top level such as $PFHOME/usr/lib/libpfdb might be a
            location where dso's would live.  In this way a
            consistent tree structure might be maintained
            regardless of Performers PFHOME directory.  (This is
            useful when using Performer installed on another
            automounted machine for instance - setenv PFHOME
            /hosts/remote_machine/)


       6.15.1.4  _C_+_+__A_P_I
       When compiling programs using Performer's C++ API, you need
       to directly include the class header files from

           ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////pppprrrr

       and

           ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffff....

       6.15.1.5  _C_o_m_p_i_l_i_n_g _P_e_r_f_o_r_m_e_r _1._2 _C++ _a_p_p_l_i_c_a_t_i_o_n_s _w_i_t_h
       _P_e_r_f_o_r_m_e_r _2._0   With Performer 2.0, compiling a Performer
       application with the C++ compiler enables the use of C++
       classes for Performer types.  Some of these Performer types
       (pfMatrix, pfVec2, pfVec3, pfVec4, pfQuat) are typedefed
       arrays when compiling with C and classes when compiling with
       C++.  Because typedefed arrays and classes differ in their
       usage, Performer applications written C++ using Performer
       1.2's C API may not compile under C++ unless Performer is
       told to revert to C types when compiling under C++.

       If you wish to compile existing C++ code using Performer C
       types add the line

           ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCCPPPPLLLLUUUUSSSSPPPPLLLLUUUUSSSS____AAAAPPPPIIII 0000''''

       before including any Performer header files.  Note that the
       use of C types precludes the use of Performer's C++ API.


       6.15.1.6  _M_i_x_i_n_g__C_+_+__A_P_I__a_n_d__C__A_P_I__i_n__a__S_i_n_g_l_e__A_p_p_l_i_c_a_t_i_o_n

       Normally, when compiling under C++, the C API routines











                                  - 42 -



       corresponding to member functions on a class are not exposed
       in the header files.  Applications wishing to taste the
       combined smorgasbord of both APIs should add the line

           ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCC____AAAAPPPPIIII 1111

       before including any Performer header files.


       6.15.2  _L_I_B_P_R__E_n_h_a_n_c_e_m_e_n_t_s

       6.15.2.1  _p_f_G_e_o_S_e_t
       PFGS_POLYS for N-sided, convex polygons. Specify the number
       of sides of each polygon with pfGSetPrimLengths().

       pfGSetPassFilter() sets a filter which allows only specific
       pfGeoSets to be drawn, e.g., a

           PPPPFFFFGGGGSSSS____NNNNOOOONNNNTTTTEEEEXXXX____GGGGSSSSEEEETTTT |||| PPPPFFFFGGGGSSSS____EEEEMMMMIIIISSSSSSSSIIIIVVVVEEEE____GGGGSSSSEEEETTTT

       filter will draw only non-textured, emissive pfGeoSets.

       pfGetGSetAttrRange() returns the number of attributes (e.g.,
       coordinates) accessed by non-indexed a pfGeoSet and the
       maximum range of indexes if the pfGeoSet is indexed.

       pfGeoSets can now index their pfGeoStates through a global
       table set by pfApplyGStateTable(). pfGSetGStateIndex() sets
       the value which is used to index the global table. Indexed
       pfGeoStates in conjunction with different pfGeoState tables
       allow drastically different appearances of a single database
       without duplicating geometry or the scene graph.  For
       example, a visual and infrared version of a database is
       easily supported with 2 different pfGeoState tables.

       pfGeoSets now accept pfCycleBuffer* as attribute lists to
       support dynamic attribute changes in a pipelined,
       multiprocessing environment.  pfCycleBuffers automatically
       manage multiple data buffers to avoid data collisions and
       ensure frame-accurate behavior of attribute changes.  This
       greatly simplifies modification of coordinates for
       sophisticated facial and skeletal animation, geometrically
       morphed level-of-detail, and special effects such as
       explosions.  Note that pfCycleBuffer nodes are obsolete with
       IRIS Performer 2.2 and that pfFlux should be used instead of
       pfCycleBuffer.


       6.15.2.2  _p_f_G_e_o_S_t_a_t_e
       pfGStateFuncs() allow pre and post callbacks on a per-
       pfGeoState basis.  The pre callback is invoked after the GL











                                  - 43 -



       has been configured with the pfGeoState's state and the post
       callback is lazily invoked by the next pfGeoState
       application so the pre/post callbacks nicely bracket
       pfDrawGSet().

       pfGStateVal() is added for floating point values and now
       accepts PFSTATE_ALPHAREF.

       pfGeoSets can now index pfGeoStates (pfGSetGStateIndex())
       through pfGeoState global tables (pfApplyGStateTable()) or
       pfGeoState tables assigned to a pfChannel
       (pfChanGStateTable()) .


       6.15.2.3  _p_f_F_o_g
       pfGetFogDensity returns the density of a pfFog at a given
       range.


       6.15.2.4  _p_f_L_P_o_i_n_t_S_t_a_t_e
       A new PFSTATE attribute, pfLPointState causes pfGeoSets of
       type PFGS_POINTS to be rendered as "light points", e.g.,
       runway lights, stars. Light points have perspective size
       based on range and many other features. This is a major
       enhancement and is discussed in great detail in the
       pfLPointState man page.


       6.15.2.5  _p_f_S_p_r_i_t_e
       A new kind of transform, pfSprite automatically rotates
       pfGeoSets and plain GL geometry to face the viewer.
       Different rotational constraints are possible including:
       rotate about an axis, rotate about a point.


       6.15.2.6  _p_f_T_e_x_G_e_n
       A new PFSTATE attribute, pfTexGen encapsulates the GL's
       texgen() feature which automatically generates texture
       coordinates. The Wavefront OBJ file loader in libpfdb
       provides an example of the use of this new capability. Refer
       to that source code for usage examples.


       6.15.2.7  _p_f_T_r_a_n_s_p_a_r_e_n_c_y
       pfTransparency now supports PFTR_MS_ALPHA_MASK which enables
       multisample transparency but also writes the true alpha
       value into the frame buffer instead of fully opaque alpha
       values as PFTR_MS_ALPHA does.














                                  - 44 -



       6.15.2.8  _p_f_D_e_c_a_l
       When using DISPLACE type decals, LAYERS are no longer
       required to be rendered immediately after their BASES - they
       can be drawn in any order. This introduces new LAYER-
       specific tokens:  PFDECAL_LAYER_FAST, PFDECAL_LAYER_DISPLACE
       and requires specific identification of all layers after the
       first since each layer must be displaced slightly more than
       its predecessor.  The tokens PFDECAL_LAYER_1 ->
       PFDECAL_LAYER_7 are provided for layer identification.


       6.15.2.9  _p_f_C_y_c_l_e_B_u_f_f_e_r_/_p_f_C_y_c_l_e_M_e_m_o_r_y

       Note that pfCycleBuffer is obsolete with IRIS Performer2.2
       in favor of the pfFlux. IRIS Performer 2.0/2.1 pfCycleBuffer
       are still included in IRIS Performer 2.2.

       A new kind of pfMemory, pfCycleBuffer supports changing data
       in a pipelined, multiprocessing environment while
       maintaining data exclusion and frame-accurate behavior. A
       pfCycleBuffer manages a set of buffers called pfCycleMemorys
       and "rotates" them each frame, advancing the data
       modifications cleanly down the processing pipeline. libpf
       transparently handles the buffer rotations.


       6.15.2.10  _p_f_P_o_l_y_t_o_p_e
       A pfPolytope is a set of N half spaces whose intersection
       defines a possibly semi-infinite, convex volume which is
       useful for culling and intersection testing where a tighter
       bound than a pfSphere, pfBox, pfCylinder, pfFrustum is of
       benefit.


       6.15.2.11  _p_f_G_L_O_v_e_r_r_i_d_e
       Adds the ability to force the use of a particular GL
       mechanism to implement a libpr feature.


       6.15.2.12  _p_f_N_o_t_i_f_y
       pfNotify has been enhanced with new formatting and modes
       (PFNFY_MORE).  Refer to the pfNotify man page for full
       details.


       6.15.2.13  _p_f_G_e_t_T_i_m_e
       New functions. Refer to the reference pages for further
       information.

           ppppffffWWWWrrrraaaappppCCCClllloooocccckkkk












                                  - 45 -



           ppppffffCCCClllloooocccckkkkNNNNaaaammmmeeee

           ppppffffCCCClllloooocccckkkkMMMMooooddddeeee

       6.15.2.14  _W_i_n_d_o_w__S_y_s_t_e_m__R_o_u_t_i_n_e_s
       New window-system interface functions provide a single API
       for creating and managing windows that works across the IRIS
       GL, IRIS GLX Mixed Mode, and OpenGL-X environments.  Window
       system independent types have been provided to match the X
       Window System types to provide complete portability between
       the IRIS GL and OpenGL-X windowing environments.


       6.15.2.15  _p_f_Q_u_e_r_y_F_e_a_t_u_r_e_/_p_f_Q_u_e_r_y_S_y_s
       New QueryFeature routines determine the presence, absence,
       or limitations of features in the underlying graphics
       implementation, like the availability of attenuation in the
       lighting model or the availability of multiple graphics
       pipes.

       The QuerySys routines determine the capacity and limitations
       of the underlying graphics implementation, like the size of
       texture memory or the number of stencil planes available.


       6.15.2.16  _p_f_T_e_x_t_u_r_e__e_x_t_e_n_s_i_o_n_s

       6.15.2.17  _I_n_t_e_g_r_a_t_e_d__T_e_x_t__S_u_p_p_o_r_t
       Two and Three dimensional font rendering is supported by the
       new pfFont (libpr), pfString (libpr), and pfText (libpf)
       primitives.

       The pfFont facility provides the capability to load fonts
       for 3-D rendering with the string drawing routines from
       pfString and pfText.  IRIS Performer uses this facility to
       provide flat, extruded, and textured-quad fonts in three
       dimensions.

       pfString provides a pfGeoSet like facility for encapsulating
       geometry to display a string in 3-D with attributes such as
       color, arbitrary transformation matrix, and font (see
       pfFont).

       A pfText node is a list of pfStrings much as a pfGeode is a
       list of pfGeoSets. The two APIs are also similar - a new
       pfText node can be created and the list of pfStrings
       attached to it can be manipulated by addition, insertion,
       removal or replacement.

       The best examples of these new font tools at present are
       hello.c and helloC.C, both provided in the IRIS Performer











                                  - 46 -



       source directory.


       6.15.2.18  _p_f_Q_u_a_t
       A full set of quaternion utilities is defined in prmath.h
       and is documented in the pfQuat man page.


       6.15.3  _L_I_B_P_F__E_n_h_a_n_c_e_m_e_n_t_s

       6.15.3.1  _M_u_l_t_i_p_l_e__W_i_n_d_o_w_s__o_n__a__s_i_n_g_l_e__p_f_P_i_p_e

       Multiple windows can now be rendered from a single pfPipe.
       This allows a single drawing process to render to multiple
       windows on a single screen.  Libpf now requires use of the
       pfPipeWindow primitive for opening windows for pfPipes.  See
       the pfWindow and pfPipeWindow (pfConfigPWin()) reference
       pages for details.


       6.15.3.2  _p_f_M_o_r_p_h

       Note that pfMorph node is obsolete in 2.2.  We recommand
       using pfFlux/pfEngines instead of pfCycleBuffer and pfMorph
       feature.

       pfMorph is a new group node intended for automatic morphing
       of pfGeoSet attributes: colors, normals, coordinates, and
       texture coordinates but which can morph any floating point
       values. pfMorph is triggered during the new APP traversal
       and linearly combines N source arrays into a single
       destination which is typically a pfCycleBuffer used as a
       pfGeoSet attribute array.  By modifying the source weights
       each frame, the application can produce sophisticated,
       frame-accurate effects such as facial and skeletal animation
       and morphed, geometric level-of-detail.


       6.15.3.3  _p_f_D_B_a_s_e
       The DBASE process is a new addition to the IRIS Performer
       multiprocessing family. It is similar to the ISECT process
       in that it can run asynchronously with respect to the main
       processing pipeline (APP->CULL->DRAW). Callback and trigger
       functions, pfDBaseFunc() and pfDBase() respectively, allow
       explicit control and customization of the DBASE function.
       The DBASE is intended for asynchronous database processing,
       particularly paging to and from disk when using large
       databases. Note that IRIS Performer does not provide a
       paging facility directly - rather it provides the tools
       which the application can use to implement database paging.
       Database deletions are carried out in pfDBase() and do not











                                  - 47 -



       slow down the synchronous pipeline if DBASE is configured as
       a separate process.


       6.15.3.4  _p_f_B_u_f_f_e_r
       pfBuffer is the primary tool for asynchronous database
       manipulations. A pfBuffer isolates database changes to a
       given process, avoiding dangerous data collisions with other
       processes when multiprocessing.  Scene graphs built in an
       asynchronous process, such as the DBASE, do not affect the
       synchronous, real-time APP->CULL->DRAW pipeline and are
       quickly and safely merged into the main processing stream
       with pfMergeBuffer().


       6.15.3.5  _p_f_M_u_l_t_i_t_h_r_e_a_d
       pfMultithread adds a new multiprocessing dimension by
       multithreading a given IRIS Performer processing stage.
       Currently, only the CULL stage may be multithreaded such
       that thread culls a pfChannel. This is expected to be very
       useful for MCO applications where many pfChannels per pipe
       cause the CULL stage to become a bottleneck.


       6.15.3.6  _P_F_T_R_A_V___A_P_P
       PFTRAV_APP is a new automated IRIS Performer traversal
       intended for behavior computation, event distribution and
       other application level functions. It is carried out in the
       APP process and is initiated directly by pfAppFrame() or
       automatically by pfSync(). A wrapper callback and callback
       data (pfAppFunc(), pfPassAppData()) and node callbacks and
       data (pfNodeTravFuncs(), pfNodeTravData()) provide
       application extensibility similar to that offered for the
       CULL, DRAW, and ISECT traversals.


       6.15.3.7  _p_f_C_h_a_n_D_a_t_a
       pfChannel passthrough data may be supplied by the
       application with pfChanData() rather than allocated by the
       pfChannel with pfAllocChanData().  This allows pfChannels to
       share a single passthrough data block.


       6.15.3.8  _p_f_C_h_a_n_C_u_l_l_P_t_o_p_e
       pfChanCullPtope() specifies that a pfChannel use a
       pfPolytope, rather than its viewing pfFrustum, for culling.
       This allows highly customized culling for specific
       environments where visibility can be predetermined to some
       extent, e.g., when in a room and looking through a door the
       cull volume can be shrunk to the door opening.












                                  - 48 -



       6.15.3.9  _p_f_C_h_a_n_N_o_d_e_I_s_e_c_t_S_e_g_s
       pfChanNodeIsectSegs() is identical to pfNodeIsectSegs() but
       includes a pfChannel to evaluate pfLODs during the
       intersection traversal.  Thus, pfChanNodeIsectSegs()
       computes intersections with the same level-of-detail as is
       selected for rendering. This greatly simplifies operations
       such as terrain following on terrain which is modeled as
       levels-of-detail.


       6.15.3.10  _p_f_C_h_a_n_G_S_t_a_t_e_T_a_b_l_e
       pfChannels can provide a pfGeoState table which is accessed
       by indexed pfGeoSets. This simplifies the management of
       multiple views of a single database, such as infrared vs.
       out-the-window.


       6.15.3.11  _p_f_V_i_d_e_o_R_a_t_e
       In release 1.2, IRIS Performer internally computed the rate
       of the video clock.  In 2.0, IRIS Performer now queries the
       video microcode for the video retrace rate or accepts the
       rate set by the application with pfVideoRate().


       6.15.3.12  _p_f_C_o_n_f_i_g_S_t_a_g_e
       pfStageConfigFunc() allows the specification of an
       initialization callback for each IRIS Performer processing
       stage. pfConfigStage() invokes specified initialization
       callbacks in the appropriate processes at the next
       pfFrame(). Initialization callbacks typically establish the
       initial conditions of a process. Examples include setting
       non-degrading priorities and locking processes to CPUs for
       real-time applications and downloading textures in the DRAW
       stage.


       6.15.3.13  _p_f_L_o_o_k_u_p_N_o_d_e
       pfLookupNode() extends pfFindNode by searching for a path-
       named node of a particular type, beginning at a specific
       node. This greatly simplifies finding named parts of a
       pfCloned subgraph.


       6.15.3.14  _p_f_S_c_e_n_e_G_S_t_a_t_e
       pfScenes can now reference a pfGeoState that defines the
       "global state" which may be inherited by other pfGeoStates
       within the scene.















                                  - 49 -



       6.15.3.15  _p_f_G_e_t_S_C_S_M_a_t_P_t_r__a_n_d__p_f_G_e_t_D_C_S_M_a_t_P_t_r
       pfGetDCSMatPtr() returns a pointer to the pfDCS matrix for
       fast access. Likewise, pfGetSCSMatPtr() returns a pointer to
       the pfSCS matrix.


       6.15.3.16  _N_e_w__G_L_-_i_n_d_e_p_e_n_d_e_n_t__W_i_n_d_o_w_i_n_g__U_t_i_l_i_t_i_e_s
       IRIS Performer now provides utilities for opening, closing,
       and managing windows.  The same routines will manage pure
       IRIS GL windows, IRIS GL-X Mixed-Mode, and OpenGL-X windows.
       Libpf application will now use the new pfPipeWindow for
       opening IRIS Performer windows.  See the pfWindow (libpr)
       and pfPipeWindow (libpf) (pfConfigPWin()) reference pages
       for details.


       6.15.3.17  _A_P_I__C_h_a_n_g_e_s
       pfSelectCtab() is now pfApplyCtab()
       pfGetMallcoSize() is now pfGetSize()
       pfGetHyperId() is now pfGetPipeHyperId()


       6.15.3.18  _R_e_f_e_r_e_n_c_e__C_o_u_n_t_i_n_g
       All pfObjects, including pfNodes now have a reference count.
       A pfGroup increments the reference count of all its
       children.


       6.15.3.19  _M_o_d_e__Q_u_e_r_y__S_e_m_a_n_t_i_c_s
       pfGetGStateAttr/Mode do not return the global values of
       inherited state elements. Instead NULL and -1 are returned.
       Use pfGetCurGStateAttr/Mode for 1.2 behavior.


       6.15.3.20  _V_i_d_e_o__C_l_o_c_k
       pfInitVClock() no longer starts and stops the video clock.
       Instead, use pfStart/StopVClock() to start and stop video
       interrupts. pfStart/StopVClock are only necessary for
       VGX/VGXT graphics and are ignored on other graphics.


       6.15.3.21  _p_f_P_i_p_e_S_c_r_e_e_n
       Proper multipipe operation now requires that pipes be
       assigned a screen (pfPipeScreen) before the first pfFrame().
       Otherwise, pipes will be automatically assigned a screen.


       6.15.3.22  _p_f_E_v_a_l_u_a_t_e_L_O_D
       pfEvaluateLOD() returns a floating point number indicating
       which child is selected by a given pfChannel. The fractional
       portion of the number is used for fading transitions.











                                  - 50 -



       6.15.3.23  _p_f_L_O_D_S_t_a_t_e
       pfLODStates are used to specify how individual LOD's or
       groups of LODs will respond to stress and range.
       pfLODStates can either be explicitly set per LOD or set as
       an index into a list of pfLODStates provided to a pfChannel.
       Thus pfLODStates can make the same pfLOD behave differently
       in different channels as well as differently under different
       stress conditions.  pfLODStates ultimately modify the range
       and fade transition calculations made by performer when
       culling.  See pfLODState, pfLOD, and pfChannel.


       6.15.3.24  _p_f_L_O_D__e_n_h_a_n_c_e_m_e_n_t_s
       pfLODs now support per-pair transition zones for fade LOD
       See the pfLODTransition reference page.

       pfLODs now respond to stress by scaling LOD ranges and
       transition zones and take a pfLODState structure to describe
       the desired stress behavior of a pfLOD. See the pfLODState
       reference page.

       LOD Priority Classes can be formed by the sharing of
       pfLODState structures across a set of LODs.

       Per-Channel LOD Priority Classes can be formed by assigning
       pfChannels with tables of pfLODStates and assigning pfLODs
       an index into these tables. See the pfChanLODAttr and
       pfLODLODStateIndex reference pages.



       6.15.4  _l_i_b_p_f_d_u__E_n_h_a_n_c_e_m_e_n_t_s

       6.15.4.1  _O_p_t_i_m_i_z_i_n_g__S_c_e_n_e__B_u_i_l_d_e_r__f_o_r__u_s_e__i_n__F_i_l_e__L_o_a_d_e_r_s
       Performer 2.0 contains a new layer of support for easily
       converting databases from external formats into performer
       runtime structures.  This new layer is called libpfdu which
       stands for library of performer database utilities.  The
       pfdBuilder contains mechanisms for completely converting
       external database formats and data into efficient IRIS
       performer structures.  The builder will take care of state
       sharing and sort your geometry by state.  Collections of
       graphics state and geometry are given to the pfdBuilder as a
       database is read in. At the end of reading a database file,
       a pfNode containing an efficient Performer representation of
       the database can be obtained.  This new API supersedes the
       previous pfuBuilder which was a simple interface for
       encapsulating geometric data into performer structures in an
       intuitive way.  This new layer of support is built on top of
       and is a superset of the previous pfuBuilder (which has now
       become the pfdGeoBuilder) that was released with Performer











                                  - 51 -



       1.2.  Check out

           ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffffdddduuuu....hhhh

       for mode settings and api for the new extended builder.

       libpfdu is the Performer library of database utilities.  Its
       purpose is to provide helpful functions for constructing
       optimized Performer data structures and scene graphs.  It is
       used mainly by database loaders which take an external file
       format containing 3d geometry and graphics state and load
       them into Performer optimized run-time only structures.
       Note that these utilities often prove very useful as most
       modeling tools and file formats represent their data in
       structures that correspond to the way users model data and
       these data structures are often necessarily mutually
       exclusive with effective and efficient Performer run-time
       structures.  libpfdu contains many utilities including dso
       support for database loaders and their modes, file path
       support, etc, but the heart of libpfdu is the notion of the
       Performer database 'builder' - pfdBuilder.

       The builder is a tool to allow users to input/output a
       collection of geometry and graphics state in immediate mode
       fashion (similar to Open/Iris GL).  Data is inputed to the
       builder one geometric primitive at a time along with its
       corresponding graphics state.  When all of the data has been
       inputed, the user simply requests optimized Performer data
       structures which can then be used as a part of a Performer
       Scene Graph.  The builder hashs geometry into different
       'bins' based on the geometry's attribute binding types and
       associated graphics state.  It also keeps track of graphics
       state elements (textures,materials,light models, fog,etc)
       and shares state elements whenever possible.  In the end,
       the builder will create Performer 'pfGeoSets' that contain
       triangle meshes created by running the original geometry
       through the libpfdu tmeshing utility.  To go along with each
       pfGeoSet, the builder builds up a Performer pfGeoState
       (Performer's encapsulated state primitive) which has been
       optimized to share as many attributes as possible with other
       pfGeoStates being build (and possibly even with a more
       global pfChannelGState).  Having created all of these
       Performer primitives (pfGeoSets and pfGeoStates) the builder
       will place them in a Performer leaf node (pfGeode), and
       possibly even artificially create a spatial hierarchy by
       running the new database through a spatial breakup utility
       function which is also contained in libpfdu.  Note that this
       builder should also allow the user to extend the notion of a
       'graphics state' by registering callback functionality
       through builder api and then treating this
       state/functionality like any other Performer state/mode











                                  - 52 -



       (although such uses of the builder are of course at least
       slightly more complicated).

       In short libpfdu is a collection of utilities that
       effectively act as a data funnel where users input flattened
       3d graphics information and are given in return fully
       functional and hopefully well optimized Performer run-time
       structures.



       6.15.5  _l_i_b_p_f_d_b__E_n_h_a_n_c_e_m_e_n_t_s

       6.15.5.1  _N_e_w__F_i_l_e__F_o_r_m_a_t_s   OpenInventor 2.0 file support.
       This is a completely new loader that uses OpenInventor
       traversal of the input scene graph to create the Performer
       scene graph, allowing robust conversion of all geometry.

       AutoDesk 3DStudio file support using the 3dsftk.

       Side Effects Software Prisms (.poly and .bpoly) file
       support.

       Medit Productions Medit (.medit) file support

       S1000 file support, based on code from Texas Instruments.

       Several other formats. Look in libpfdb for the complete
       list.


       6.15.6  _S_t_r_u_c_t_u_r_a_l__C_h_a_n_g_e_s

       6.15.6.1  _C_l_a_s_s__s_t_r_u_c_t_u_r_e
       One of the major differences from 1.2 is that libpr is now
       written in C++ and the class tree has changed. 1.2 had both
       a prObject and pfObject - now there is a single pfObject
       which is derived from IRIS Performer's base class, pfMemory.
       There are no more pr-prefixed routines which were used for
       libpr->libpf inheritance, e.g, pfLight -> pfLightSource.


       6.15.6.2  _p_f_T_y_p_e
       IRIS Performer has changed its type system to support new,
       application-derived types. pfGetType() now returns a pfType*
       instead of a bitmask. Each IRIS Performer data type which
       has an explicit allocator (usually pfNew*()) has an
       associated pfType which is created at initialization time by
       pfInit().  The pfType corresponding to a particular class is
       returned by pfGet<*>ClassType(), e.g.,
       pfGetGroupClassType().











                                  - 53 -



       The primary difference in 2.0 is the fact that types are no
       longer represented with bitmasks where the inheritance chain
       of a particular type is encoded in the bitmask, e.g.,
       PFTYPE_SCS == (100 | PFCLASS_SCS | PFCLASS_GROUP |
       PFCLASS_NODE), indicating that SCS is derived from pfGroup
       and pfNode.  pfType is an opaque data structure whose
       inheritance chain must be queried through pfIsOfType().

       Here are the old and new methods for testing an object for
       exact type equality. The 1.2 method:

           iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== PPPPFFFFTTTTYYYYPPPPEEEE____SSSSCCCCSSSS))))

       and the 2.0 methods, which are equivalent

           iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))

           iiiiffff ((((ppppffffIIIIssssEEEExxxxaaaaccccttttTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))

       Here are the old and new methods for testing an object for
       derivation from a give type. The 1.2 method:

           iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) &&&& PPPPFFFFCCCCLLLLAAAASSSSSSSS____GGGGRRRROOOOUUUUPPPP))))

       and the 2.0 method

           iiiiffff ((((ppppffffIIIIssssOOOOffffTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttGGGGrrrroooouuuuppppCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))

       Special care should be taken when porting to the new type
       API.


       6.15.7  _C_h_a_n_g_e_s__i_n__l_i_b_p_r

       6.15.7.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
       PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
       by default.  Databases created with loaders that assumed
       specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
       be rendered improperly. All IRIS Performer loaders shipped
       with 2.0 create pfGeoStates that assume the global default
       is the same as that set by pfBasicState(), i.e., everything
       is OFF.


       6.15.7.2  _L_i_n_e__W_i_d_t_h__a_n_d__P_o_i_n_t__S_i_z_e
       pfGeoSets with linewidth/pointsize of <= 0 will not set
       linewidth or pointsize but will inherit it through the GL.















                                  - 54 -



       6.15.7.3  _A_l_p_h_a__R_e_f_e_r_e_n_c_e__V_a_l_u_e
       The PFSTATE_ALPHAREF state element has changed from an
       integer in the range 0-255 to a float in the range 0-1 and
       is now set on pfGeoStates with the new routine, pfGStateVal.
       A warning will be generated if set through pfGStateMode.


       6.15.7.4  _D_e_c_a_l__I_m_p_l_e_m_e_n_t_a_t_i_o_n
       pfDecal no longer sets zwritemask to 0 when drawing
       displaced layers.  This allows layers to be drawn separately
       from their bases, enabling improved sorting by graphics
       mode.


       6.15.7.5  _M_a_t_h__F_u_n_c_t_i_o_n_s
       pfXformPt3/Vec3 previously considered the last column of the
       matrix and divided by the homogeneous coordinate, w. The new
       pfXformPt3/Vec3 are much faster and treats the pfMatrix as a
       4x3 matrix.  The old behavior is now accessed through the
       new pfFullXformPt3/Vec3 routines.

       pfInvertMat is now named pfInvertFullMat but a #define
       ensures 1.2 compatibility.

       pfMakeRotOntoMat is obsoleted in favor of the much faster
       pfMakeVecRotVecMat which assumes normalized input vectors.


       6.15.7.6  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
       pfFrustAspect is no longer persistent. In 1.2, automatic
       frustum calculation (e.g. PFFRUST_CALC_HORIZ) was always in
       effect once set. In 2.0, pfFrustAspect recomputes the
       frustum only at time of invocation.


       6.15.8  _C_h_a_n_g_e_s__i_n__l_i_b_p_f

       6.15.8.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
       PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
       by default.  Databases created with loaders that assumed
       specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
       be rendered improperly. All IRIS Performer loaders shipped
       with 2.0 create pfGeoStates which assume the global default
       is the same as that set by pfBasicState(), i.e., everything
       is OFF. To achieve 1.2 behavior with 1.2 loaders, call the
       following in the DRAW process after the window is opened:

           ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____LLLLIIIIGGGGHHHHTTTTIIIINNNNGGGG))));;;;

           ////**** OOOOnnnnllllyyyy oooonnnn IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy////RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee////IIIImmmmppppaaaacccctttt////VVVVGGGGXXXXTTTT////VVVVGGGGXXXX ****////
           ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____TTTTEEEEXXXXTTTTUUUURRRREEEE))));;;;











                                  - 55 -



           ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____FFFFOOOOGGGG))));;;;

       6.15.8.2  _M_u_l_t_i_-_c_h_a_n_n_e_l__f_o_g__a_n_d__l_i_g_h_t_i_n_g__c_o_n_s_i_s_t_e_n_c_y
       pfChannels now encode rotational offsets (pfChanViewOffsets)
       in the ModelView instead of the Projection matrix.
       Consequently, fog always matches across adjacent pfChannels
       but for proper lighting, a local viewer lighting model is
       required (pfLModelLocal).


       6.15.8.3  _T_y_p_e__i_n_h_e_r_i_t_a_n_c_e
       Multiple inheritance through the C API is gone. Previously,
       pfChannels could use pfFrustum API, e.g.,
       pfMakePerspFrust(chan,...) pfFrameStats could use pfStats
       API, and pfLightSources could use pfLight API, e.g.,
       pfLightPos(lsource...). Additional routines are now provided
       to maintain the same functionality without the complexities
       of multiple inheritance. The new routines name are simply
       the old routines where the "base" class name is replaced
       with the "derived" class name. For example, pfMakePerspFrust
       becomes pfMakePerspChan and pfLightPos becomes pfLSourcePos.
       Comprehensive tables illustrating the correspondence between
       routine names are found in pfChannel, pfFrameStats, and
       pfLightSource man pages.


       6.15.8.4  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
       Customizing a viewing frustum with pfMakePerspChan or
       pfMakeOrthoChan now disables the automatic viewport aspect
       ratio matching feature of pfChannel (pfChanAutoAspect).


       6.15.8.5  _A_P_I__C_h_a_n_g_e_s
       pfChanCullFunc and pfChanDrawFunc are now subsumed by
       pfChanTravFunc.

       pfStageConfigFunc() and pfConfigStage() replace the now
       obsolete pfInitPipe().


       6.15.8.6  _B_u_g__f_i_x
       PFPHASE_FLOAT and PFPHASE_LOCK now work in single process
       mode.


       6.15.8.7  _p_f_S_w_i_t_c_h__s_e_m_a_n_t_i_c_s
       pfSwitchVal() used to determine the validity of the switch
       value which was problematic if no children had been added to
       the pfSwitch yet. The validity check is now deferred to
       individual traversal routines.












                                  - 56 -



       6.15.8.8  _p_f_D_a_t_a_P_o_o_l_s
       When Performer shared memory has been created, pfDataPools
       are now positioned in the virtual address space so that
       conflicts are less likely to arise.  Such conflicts were a
       frequent cause of failures of pfAttachDPool.  Deleting a
       data pool now detaches it from the address space.


       6.15.8.9  _p_f_P_a_r_t_i_t_i_o_n_s
       Allow better specification of the spacing and positioning of
       the spatial partition to reduce construction time. They also
       work now.


       6.15.8.10  _O_t_h_e_r__C_h_a_n_g_e_s


       6.15.8.11  _E_l_i_m_i_n_a_t_i_o_n__o_f__m_u_l_t_i_p_l_e__i_n_h_e_r_i_t_a_n_c_e
       The CAPI inheritance of pfChannel from pfFrustum,
       pfLightSource from pfLight and pfFrameStats from pfStats has
       been removed.  API has been added on the formerly derived to
       duplicate the functionality of the former base class, e.g.
       pfApplyFrust(chan) -> pfApplyChan(chan).


       6.15.8.12  _L_i_g_h_t__M_o_d_e_l__A_t_t_e_n_u_a_t_i_o_n__v_s__L_i_g_h_t__A_t_t_e_n_u_a_t_i_o_n
       IRIS GL: Light Attenuation is on the pfLightModel

           vvvvooooiiiidddd ppppffffLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
               ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;

           vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
               ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;

       OpenGL: Light Attenuation is on the pfLight

           vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
               ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;

           vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
               ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;

       6.15.8.13  _p_f_A_l_p_h_a_F_u_n_c__n_o_w__t_a_k_e_s__a__f_l_o_a_t__f_o_r__r_e_f

           wwwwaaaassss:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;

           nnnneeeewwww:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;

       6.15.8.14  _p_f_G_e_t_A_l_p_h_a_F_u_n_c__n_o_w__r_e_t_u_r_n_s__a__f_l_o_a_t__f_o_r__r_e_f

           wwwwaaaassss:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;











                                  - 57 -



           nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;

       6.15.8.15  _p_f_G_S_t_a_t_e_M_o_d_e__a_n_d__p_f_G_e_t_G_S_t_a_t_e_M_o_d_e
       pf{Get}GStateMode can no longer accept the PFSTATE_ALPHAREF
       token.  Use

           ppppffffGGGGSSSSttttaaaatttteeeeVVVVaaaallll((((ggggssssttttaaaatttteeee,,,, PPPPFFFFSSSSTTTTAAAATTTTEEEE____AAAALLLLPPPPHHHHAAAARRRREEEEFFFF,,,, vvvvaaaallll))));;;;

       6.15.8.16  _p_f_L_i_g_h_t_C_o_l_o_r__a_n_d__p_f_G_e_t_L_i_g_h_t_C_o_l_o_r
       pfLightColor and pfGetLightColor now take arguments to
       specify which color.

           wwwwaaaassss:::: ppppffffLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaannnndddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaarrrreeee oooobbbbssssoooolllleeeetttteeee....

           nnnneeeewwww:::: vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
                   ffffllllooooaaaatttt rrrr,,,, ffffllllooooaaaatttt gggg,,,, ffffllllooooaaaatttt bbbb))));;;;

           nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
                   ffffllllooooaaaatttt**** rrrr,,,, ffffllllooooaaaatttt**** gggg,,,, ffffllllooooaaaatttt**** bbbb))));;;;

       6.15.8.17  _p_f_I_n_i_t_G_f_x
       pfInitGfx() has changed API, location and behavior:

           wwwwaaaassss:::: vvvvooooiiiidddd ppppffffIIIInnnniiiittttGGGGffffxxxx((((ppppffffPPPPiiiippppeeee ****pppp))));;;;

           nnnneeeewwww:::: ppppffffIIIInnnniiiittttGGGGffffxxxx((((vvvvooooiiiidddd))));;;;

       pfInitGfx() should now be used to initialize all pfWindows
       and pfPipeWindows.


       6.15.8.18  _p_f_I_n_i_t_G_L_X_G_f_x
       pfInitGLXGfx(pfPipe *) has been removed. Use the
       pfPipeWindow utilities.


       6.15.8.19  _p_f_G_e_t_P_i_p_e_W_i_n__a_n_d__p_f_G_e_t_P_i_p_e_G_L_X_W_i_n_s
       pfGetPipeWin and pfGetPipeGLXWins have been removed. There
       is now pfGetPipePWin() to support this functionality.


       6.15.8.20  _p_f_I_n_i_t_P_i_p_e
       pfInitPipe() is obsoleted in favor of pfStageConfigFunc()
       and pfConfigStage().  pfInitPipe() no longer is used to
       create windows.  Use pfConfigPWin for a window
       initialization callback.  Use pfConfigStage for initializing
       (or later re-configuring) the CULL or DRAW processes
       (stages) for a given pipe.














                                  - 58 -



       6.15.8.21  _p_f_G_e_t_P_i_p_e_O_r_i_g_i_n
       pfGetPipeOrigin() has been removed.  Use pfGetWinOrigin() or
       pfGetPWinOrigin() to get the size of a pfWindow or
       pfPipeWindow respectively.


       6.15.8.22  _p_f_G_e_t_P_i_p_e_S_i_z_e
       pfGetPipeSize() now returns the screen size of a pfPipe. Use
       pfGetWinSize() or pfGetPWinSize() to get the size of a
       pfWindow or pfPipeWindow respectively.


       6.15.8.23  _p_f_u_W_i_d_g_e_t_F_u_n_c__r_e_n_a_m_e_d
       pfuWidgetFunc() is now pfuWidgetActionFunc().


       6.15.8.24  _p_f_u_E_n_a_b_l_e_P_a_n_e_l
       pfuEnablePanel() no longer takes an enable argument.
       Instead, pfuPanels are enabled/disabled with
       pfuEnablePanel() and pfuDisablePanel() respectively.


       6.15.8.25  _p_f_u_G_e_t_P_a_n_e_l_S_i_z_e
       pfuGetPanelSize now follows standard convention of (xo, yo,
       xs, ys) parameter ordering.

           wwwwaaaassss:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
                    iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****yyyyssss))));;;;

           nnnneeeewwww:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllOOOOrrrrggggSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
                    iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyssss))));;;;

       6.15.8.26  _p_f_I_n_i_t_P_W_i_n
       pfInitPWin is now pfConfigPWin